AK4493 DAC

Thank you for your kind words. :)

But what makes you say that my AK4490 design was more elaborate?

Probably he has not red the AK4493 article thoroughly. Nothing is "missing" compared to your AK4490 article.
I have learned so much from it and got the needed push for my own project.
So, Dimdim, let me thank you VERY, VERY much here for posting that info and code publicly.

Best regards, Kovax
 
Thank you for your kind words. :)

But what makes you say that my AK4490 design was more elaborate?

Well, in the blog of the AK4490 you didn't have an outputstage yet, there also wasn't a receiver or anything. They were all included in the blog resulting in 3 modules that could receive data, convert it to analog and then drive a line level signal. It was a whole product!


Though I clearly understand why you didn't go through all of that. The outputstage has been reused, the receiver board (with the XMOS module) is such a big project that it could be one on it's own.

By the way, I plan on also using the AK4118, you you use seperate clocks for the DAC and the ASRC? I thought they had to be synchronous?
 
Probably he has not red the AK4493 article thoroughly. Nothing is "missing" compared to your AK4490 article.
I have learned so much from it and got the needed push for my own project.
So, Dimdim, let me thank you VERY, VERY much here for posting that info and code publicly.

Best regards, Kovax

You are very, very welcome Kovax. I'm happy that I've been able to help.
 
Well, in the blog of the AK4490 you didn't have an outputstage yet, there also wasn't a receiver or anything. They were all included in the blog resulting in 3 modules that could receive data, convert it to analog and then drive a line level signal. It was a whole product!

Yes, I suppose that 3 long posts do convey a lot more info than one measly post with what is essentially just an update to an older post. But I'm afraid that the idea was exactly that, to convey only the new information, in a brief manner. I do intend to compile all of this information into one single project page (like I have done with the Buffalo and the Soekris DACs). You will have to wait a bit for that, though. The dac still needs to go into a proper enclosure..

Though I clearly understand why you didn't go through all of that. The outputstage has been reused, the receiver board (with the XMOS module) is such a big project that it could be one on it's own.

Exactly. The same output stage will also be reused in the AK4497 dac that is in the pipeline. Unfortunately it will need to be adapted with an I/V stage for use in the AK4499 dac (also in the pipeline).

The XMOS module is a different matter. I would hate for it to end up being copied and sold on Ebay so I'll be providing info on it only upon request (via PM or email). Plus XMOS does not allow me to share my source code, only binaries.

By the way, I plan on also using the AK4118, you you use seperate clocks for the DAC and the ASRC? I thought they had to be synchronous?

They do need to be synchronous, so what I'm doing for USB input is using the Si544 to clock the XMOS chip, the flip-flop and the DAC chips, but for s/pdif input I am disabling the Si544 and using the AK4118's generated MCLK to clock the flip-flops and DAC chips. There is no ASRC on this board, since I only included the s/pdif inputs for convenience, not for "serious use".

The AK4497 I'm developing has a better s/pdif input scheme, with ASRC functionality.
 
...for USB input is using the Si544 to clock the XMOS chip, the flip-flop and the DAC chips, but for s/pdif input I am disabling the Si544 and using the AK4118's generated MCLK to clock the flip-flops and DAC chips. There is no ASRC on this board, since I only included the s/pdif inputs for convenience, not for "serious use".

Si544 is for "serious" audio use? Don't know why that would be.
 
Yes, I suppose that 3 long posts do convey a lot more info than one measly post with what is essentially just an update to an older post. But I'm afraid that the idea was exactly that, to convey only the new information, in a brief manner. I do intend to compile all of this information into one single project page (like I have done with the Buffalo and the Soekris DACs). You will have to wait a bit for that, though. The dac still needs to go into a proper enclosure..



Exactly. The same output stage will also be reused in the AK4497 dac that is in the pipeline. Unfortunately it will need to be adapted with an I/V stage for use in the AK4499 dac (also in the pipeline).

The XMOS module is a different matter. I would hate for it to end up being copied and sold on Ebay so I'll be providing info on it only upon request (via PM or email). Plus XMOS does not allow me to share my source code, only binaries.



They do need to be synchronous, so what I'm doing for USB input is using the Si544 to clock the XMOS chip, the flip-flop and the DAC chips, but for s/pdif input I am disabling the Si544 and using the AK4118's generated MCLK to clock the flip-flops and DAC chips. There is no ASRC on this board, since I only included the s/pdif inputs for convenience, not for "serious use".

The AK4497 I'm developing has a better s/pdif input scheme, with ASRC functionality.

The AK4118 supports a local oscillator, wouldn't it be better to use your Si544 masterclock to clock the AK4118 and everything else? The SPDIF and AES/EBU clocks are known to be very jittery and reclocking (with a low jitter master clock) is necessary for good performance!

How would one approach clocking with a DSP between the ASRC and DAC. Would the DSP clock be a multiple of the master clock and locked with a PLL?
 
The SPDIF and AES/EBU clocks are known to be very jittery and reclocking (with a low jitter master clock) is necessary for good performance!

AK4118 cannot reclock incoming SPDIF, that's not what it uses the optional oscillator for. AKM makes AK4137 if reclocking is desired.

However, I agree with your statement above that low jitter is needed for best sound quality. Some other people apparently disagree. Everyone has their own opinion, of course.
 
Last edited:
AK4118 cannot reclock incoming SPDIF, that's not what it uses the optional oscillator for. AKM makes AK4137 if reclocking is desired.

However, I agree with your statement above that low jitter is needed for best sound quality. Some other people apparently disagree. Everyone has their own opinion, of course.

I really dislike modulation distortion and IMD. Jitter is one cause of that. Some people think you can't hear it or it's not relevant, because of the low level it occurs.

I think you can still hear it. However I think we should keep things in perspective. Acoustic treatment outweighs the effect of a DAC improvement in the general living room. However that doesn't mean we can't hear it!

Besides that, if you put so much effort in designing a DAC. You might as well invest 20 euro's in a good quality oscillator and pay extra attention to coupling and PCB lay out.
 
AK4118 cannot reclock incoming SPDIF, that's not what it uses the optional oscillator for. AKM makes AK4137 if reclocking is desired.

However, I agree with your statement above that low jitter is needed for best sound quality. Some other people apparently disagree. Everyone has their own opinion, of course.

Now that we are talking about input receivers anyway. I was already going to reclock AND use the AK4137 ASRC. I'll also be using TWTMC as oscillator (11.2896MHz) and use this as master clock for the DAC, reclocking circuit (pretty much the same as DimDim's new version), the ASRC and input receiver.

Since the masterclock is only a multiple of 44.1kHz (I chose this, because non-linear distortion of the AK4493 is lowest at this sample rate according to the datasheet). Can I still receive 48kHz and it's multiples?

I assume that the AK4137 is able to convert the SR to 44.1kHz, after all it's what it is supposed to do.
I also read about jitter reduction by running the DAC at an odd sample rate. It's not very elaborated and can be found here: https://www.hypex.nl/img/upload/doc/an_wp/WP_AES123BP_the_engineers_survival_guide.pdf (slide 92 to 100). How does one do this? I thought the DAC clock had to be a multiple of 44.1k or 48k? Though 1Hz deviation won't be audible. How does one configure this?
 
ESS dacs are often clocked at 100MHz which is possible because they have internal ASRC. I once divided the ESS 100MHz clock by 4 to produce a 25MHz clock that was then used as the reference clock for AK4137. It worked just as well as if the reference clock were 24.576MHz. After all, how would dacs and or ASRCs know what the frequency is other than from the attached clock?

Regarding downsampling from 48kHz to 44.1kHz, some ASRCs may perform worse when downsampling. Data sheets should hopefully say what to expect (although AK4137 data sheet has been criticized by some for alleged shortcomings). One might also take a look at ASRC specs to see how reclocking from 44.1 to 44.1 fares performance-wise. If it doesn't look as good as resampling to a more "different" frequency, then perhaps using an "odd" dac sample rate would allow one to avoid such a situation in all cases. The biggest problem using an odd sample rate IME is to find low jitter clocks at other than audio frequencies. Of course, there are some very good 10MHz clocks, but then a lot of downsampling might be in store.

Another issue with using ASRC when not really needed, such as for USB sources, is that hardware ASRCs always have some audible effects. The audible effects can be a little worse if ASRC PLL power quality is not clean enough.
 
ESS dacs are often clocked at 100MHz which is possible because they have internal ASRC. I once divided the ESS 100MHz clock by 4 to produce a 25MHz clock that was then used as the reference clock for AK4137. It worked just as well as if the reference clock were 24.576MHz. After all, how would dacs and or ASRCs know what the frequency is other than from the attached clock?

Regarding downsampling from 48kHz to 44.1kHz, some ASRCs may perform worse when downsampling. Data sheets should hopefully say what to expect (although AK4137 data sheet has been criticized by some for alleged shortcomings). One might also take a look at ASRC specs to see how reclocking from 44.1 to 44.1 fares performance-wise. If it doesn't look as good as resampling to a more "different" frequency, then perhaps using an "odd" dac sample rate would allow one to avoid such a situation in all cases. The biggest problem using an odd sample rate IME is to find low jitter clocks at other than audio frequencies. Of course, there are some very good 10MHz clocks, but then a lot of downsampling might be in store.

Another issue with using ASRC when not really needed, such as for USB sources, is that hardware ASRCs always have some audible effects. The audible effects can be a little worse if ASRC PLL power quality is not clean enough.

The AK4137 has true bypass function AFAIK. If it doesn't it's not difficult to make it yourself with logic gates/flipflops.

As for the odd oscillator frequencies, you can always use a VCO and put an frequency offset. The example used in the AES presentation I send uses a 25Hz offset. That should definitely be possible. 1ppm of 11MHz is already 11Hz and it seriously reduces jitter artifacts as can be seen in their measurements.

I'm just wondering how the AK4118 can receive the clock with a 11.2896 MHz reference. I understand the 44.1kHz, but how does it receive the 48kHz and multiples?
 
Si544 is for "serious" audio use? Don't know why that would be.

I started using these Si5xx oscillators mainly because of practical reasons, in order to test out the effect of different MCLK frequencies on the dac chips. The idea was to use the optimum MCLK frequency for each SR.

Along the way I realized that the Si570 was performing very, very well, both in terms of SQ as well as in terms of measured performance.

I did consider using two fixed frequency oscillators but that thought gradually faded away once it occurred to me that such a solution might even prove to be inferior, since it would essentially compromise the (very tight) layout, needing (ideally) one more LDO.

Plus Soekris was (and still is) using the much lower performing Si514 on their DAM boards with excellent results.

Then the Si544 came out, with even better specs than the Si570, and all of my doubts went away for good.

It looks like these oscillators will prove to be even more practical in my new design where otherwise there would be a need for 4 different oscillators.
 
The AK4118 supports a local oscillator, wouldn't it be better to use your Si544 masterclock to clock the AK4118 and everything else? The SPDIF and AES/EBU clocks are known to be very jittery and reclocking (with a low jitter master clock) is necessary for good performance!

How would one approach clocking with a DSP between the ASRC and DAC. Would the DSP clock be a multiple of the master clock and locked with a PLL?

The local oscillator on the AK4118 only serves as a reference with which to compare the incoming s/pdif signal in order to calculate its sampling rate. It doesn't have anything to do with generating the master clock. That is "extracted" from the s/pdif stream.

Like Mark said, one could use the AK4137 to do ASRC duties, being clocked from the DAC's MCLK. But in my tests such a solution, although technically 100% valid, did not give the best (audible) results. The AK4137 always "took something away" from the SQ. Ironically, I got the best SQ by clocking the dac chips from the Si570 and not using the AK4118-generated mclk at all. Yes, that is definitely the wrong way to do this, but with actual music the end result was actually considerably better. But with test tones there would be audible glitches.
 
The local oscillator on the AK4118 only serves as a reference with which to compare the incoming s/pdif signal in order to calculate its sampling rate. It doesn't have anything to do with generating the master clock. That is "extracted" from the s/pdif stream.

Oooh, now I get it. I thought it needed the masterclock to send data out synchronous with the masterclock in case one doesn't use an ASRC. Your statement makes more sense. Thanks!

I sometimes find it hard to understand what a chip EXACTLY does and what it doesn't. AKM's datasheets aren't always that clear, but atleast they don't require me to sign a NDA like ESS.