Yes, given at least some people can hear differences that are supposed to be inaudible to the ear, we should keep an open mind.
This thread is a good example: DAC Blind Test Series | Super Best Audio Friends
Not really. Aside from some questions about the methodology, he's compared two DACs that are total garbage and not transparent. If I owned a DAC that measured like those, I'd consider it broken.
Are you talking about reclocking MCLK needing 49.152 vs 24.576 if you want to keep 768 kHz as an option? I'm a bit confused.
For AK4499 an MCLK of 22.5792 is needed to play DSD512. The BCLK frequency of DSD512 is also 22.5792. Running that through a D-flip flop reclocker will divide BCLK frequency by two. It effectively amounts to the same thing as a D-FF frequency divider circuit. A reclocker circuit requires clocking at least twice the frequency of that signal being reclocked so that there can be one sample of, say, the BCLK high state, and one sample of the BCLK low state (so as to work as as reclocker, if that makes sense). This assumes we are only using the leading edge of MCLK to do the reclocking.
Last edited:
Well, I’m sure he’s open to testing something for you if you ask. Would be better than trying to educate people that will never agree with you.
Mark, possibly you misunderstood, what I meant was reclocking right at the
discrete resistor DAC array. So the OP resistor array is switched with the lowest
possible jitter signal. You don't have this level of control with a chip.
TCD
For the lowest jitter, yes, but the input circuitry, of the DAC resistor array, is going to swamp out any of those long term crystal stability or phase noise performance improvements anyway. That's the point.
This is true. I am also not sure it makes any difference to reclock BCLK or LRCK before it enters the chip. Certainly not in PCM mode for AK4499, but I am not 100% aware of the internal architecture and how it processes DSD.
My understanding from the chip guys (and girls) is that current generation DACs and ADC's reclock internally. You do not need a 2X clock to reclock, just a delay long enough to ensure the data transition is stable before clocking it through a dflop running a "synchronous" clock. These tricks go way back (tuning the discrete transistor logic clock tree in a CDC7600 for example) and are resurfacing in some new leading edge non-clocked logic design.
I can understand the desire to reclock on a discrete R2R DAC, but for that to be meaningful at the picoSecond level you have some serious layout issues to resolve. Not to mention skew in the switching time of the logic. The plot below from TI shows what happens to your transition when more than one output switches. (https://www.ti.com/lit/an/sdya009c/...35015&ref_url=https%3A%2F%2Fwww.google.com%2F) Your femtoSecond jitter just got modulated by the audio waveform. . . This is why clock analyzers are a great tool but cannot replace proper analysis of the analog output.
I can understand the desire to reclock on a discrete R2R DAC, but for that to be meaningful at the picoSecond level you have some serious layout issues to resolve. Not to mention skew in the switching time of the logic. The plot below from TI shows what happens to your transition when more than one output switches. (https://www.ti.com/lit/an/sdya009c/...35015&ref_url=https%3A%2F%2Fwww.google.com%2F) Your femtoSecond jitter just got modulated by the audio waveform. . . This is why clock analyzers are a great tool but cannot replace proper analysis of the analog output.
Attachments
It's one of the fundamental limitations of R2R ladder DACs. There are many others too.
But you have also highlighted a fundamental advantage of a native DSD (or PDM) type DAC with multiple unity weighted bits arranged in a moving average topology.
a/ Any clock delay does not affect linearity at all as long as the clock delay is constant for that particular OP bit.
b/ The bit switching time skew can be addressed with RTZ encoding where it is very effectively nulled.
TCD
Yeah, and it’s standard practice to use clock domain crossing techniques where necessary internally. Since most converters don’t require specific phase relationships between the serial data clocks and the master clock, there is definitely some synchronizer or short FIFO there.
I think it is fair to say that many current DAC chips are different in these regards, and can be used in different ways as well. For example, ESS has an onboard DPLL, and an onboard ASRC, but both of these can be disabled as the implementation chooses.
I am not sure what is going on in the AKM 4499, but if one uses it in its "DSD direct" mode, it certainly appears from the data sheet that it does nothing more than send the DSD data directly to the output stage, although it is not entirely clear what happens to the clock signal/bit clock. As it appears that most DAC chip makers want to keep some aspects of their designs proprietary, we may not be able to know exactly how things are handled internally.
All the more reason for really clever designers to go to discrete solutions, so that they have full control of all aspects of the performance. The following is from Bruno Putzeys, explaining why he chose to use a discrete approach for his Mola Mola DAC design:
"It's kinda funny, it feels almost like a blast from the past as I did this DAC design in 2013... It wasn't a single handed job btw. I did the schematics and prepared all the algos in MATLAB and my mate Bart van der Laan then rolled the circuit boards and did some heroic assembly language coding.
In case anyone's wondering why I decided to go discrete, I actually started testing existing sigma-delta DAC chips first but could find none that didn't have idle tones. I suspect that is still the case. Chip manufacturers usually manage to move these out of the band at mid-scale (i.e. zero or small signal), but they show up in a THD vs level graph as a small increase in apparent noise typically starting at -20dBfs. Basically this "noise" are tones that are swept in and out of the audio band, frequency modulated by the signal. The simplest way of testing for this is to do a noise level vs DC input plot. The tones, when they appear, are well above the noise floor, even as integrated over the audio band. Using PWM as a conversion format solves this tone problem, but nobody is doing that on an IC. Hence the discrete design. I won't speculate on the audibility of this phenomenon but anything that is measurable is fair game for me. If people are going to shell out serious moolah for a DAC, least thing you can do is show an objectively provable benefit. Low jitter is also something I like to that's why we ended up coding our own ASRC algorithm."
The above is captured from Bruno's comment on the Mola Mola Tambaqui DAC review at ASR.
On re-clocking before the conversion stage, my understanding is that some form of re-clocking is going to be necessary if we are using an isolated USB input, as the isolators themselves are going to be adding considerable timing problems. The usual way this is done is to re-clock after the data emerges from the isolators, before the input to the conversion stage, via the local masterclock (master clock is sent back through the isolator to the USB receiver) to align all the data lines with the masterclock just before the conversion stage.
I am not sure what is going on in the AKM 4499, but if one uses it in its "DSD direct" mode, it certainly appears from the data sheet that it does nothing more than send the DSD data directly to the output stage, although it is not entirely clear what happens to the clock signal/bit clock. As it appears that most DAC chip makers want to keep some aspects of their designs proprietary, we may not be able to know exactly how things are handled internally.
All the more reason for really clever designers to go to discrete solutions, so that they have full control of all aspects of the performance. The following is from Bruno Putzeys, explaining why he chose to use a discrete approach for his Mola Mola DAC design:
"It's kinda funny, it feels almost like a blast from the past as I did this DAC design in 2013... It wasn't a single handed job btw. I did the schematics and prepared all the algos in MATLAB and my mate Bart van der Laan then rolled the circuit boards and did some heroic assembly language coding.
In case anyone's wondering why I decided to go discrete, I actually started testing existing sigma-delta DAC chips first but could find none that didn't have idle tones. I suspect that is still the case. Chip manufacturers usually manage to move these out of the band at mid-scale (i.e. zero or small signal), but they show up in a THD vs level graph as a small increase in apparent noise typically starting at -20dBfs. Basically this "noise" are tones that are swept in and out of the audio band, frequency modulated by the signal. The simplest way of testing for this is to do a noise level vs DC input plot. The tones, when they appear, are well above the noise floor, even as integrated over the audio band. Using PWM as a conversion format solves this tone problem, but nobody is doing that on an IC. Hence the discrete design. I won't speculate on the audibility of this phenomenon but anything that is measurable is fair game for me. If people are going to shell out serious moolah for a DAC, least thing you can do is show an objectively provable benefit. Low jitter is also something I like to that's why we ended up coding our own ASRC algorithm."
The above is captured from Bruno's comment on the Mola Mola Tambaqui DAC review at ASR.
On re-clocking before the conversion stage, my understanding is that some form of re-clocking is going to be necessary if we are using an isolated USB input, as the isolators themselves are going to be adding considerable timing problems. The usual way this is done is to re-clock after the data emerges from the isolators, before the input to the conversion stage, via the local masterclock (master clock is sent back through the isolator to the USB receiver) to align all the data lines with the masterclock just before the conversion stage.
Last edited:
I don't think that is all that happens, but it isn't clear from the datasheet. Just like the ESS DAC, the actual converter is multi-bit and so there probably still needs to be conversion to the internal 6-bit or whatever format it's using. It is unclear what the width of the data coming out of the DSD interface block is.
This is not true. There are no timing problems with isolators other than a small propagation delay. Most modern converter ICs do not care about the phase of BCK/LRCK relative to MCLK. The jitter on the I2S is not important as the conversion is ultimately clocked by MCLK or a direct derivative.
Last edited: