< 0.5ps jitter for digital audio: nonsense, or am I missing something?

[rs20]

On page 2 of Jitter in (Digital) Audio, the author claims that the jitter of the DAC clock in an audio system must be < 0.5ps or else the stereo image would be 'blurred':

With AD- as well as with DA-conversion a clock oscillator 'of good quality' should be used. But what is good quality in this case? Well, the clock jitter should be < 0.5 ps. But this is not all. Recently phase noise close to the carrier (‘close in noise’) below about 100 Hz turned out to be the most miserable! It blurs the stereo image: the voices and instruments become wider and the sound stage becomes less deep. The phase noise of the clock should not exceed -130 dBc@10Hz!

This tingled my skeptical senses, so I did a few basic calculations assuming a 20kHz tone (maximum gradient therefore maximum jitter impact), 1 picosecond jitter (unacceptable jitter apparently). Assuming the audio signal ranges from -1 to 1, the max gradient is 2*pi*20000 units per second. Multiply the gradient by jitter to get the maximum (/typical?) error, and represent in dB: it comes to 138 dB below the tone. Therefore, if the discrepancy/error signal is to be at the borderline of audibility at 0 dB SPL, the sine wave would have to be playing at 138 dB SPL, which is beyond the threshold of pain for almost all people.

So is the demand for < 0.5 picosecond jitter in the DAC clock absurd, or have I made an error in my reasoning above?

[BrianHG]

<0.5ps Bullshit.
<0.5ns  Bullshit.
around 0.5us maybe.
around 0.5ms yes.

What kind of lousy DAC has this author been using?

[ataradov]

You are missing $$$ that you can extract from suckers.

[Paul Moir]

Better keep the microphone's diaphram consistent well less than a nanometer.  And of course you'll need your speakers encased in a few tonnes of concrete to keep them from moving so much.

[KE5FX]

A/B or GTFO

[Someone]

<0.5ps Bullshit.
<0.5ns  Bullshit.
around 0.5us maybe.
around 0.5ms yes.

What kind of lousy DAC has this author been using?

Or in fact you know nothing? How about learning from the experts:
http://cds.linear.com/docs/en/design-note/dn1013f.pdf
ps of jitter is right on the ballpark for a high quality clock source when you consider distribution and noise.

A/B or GTFO

Or go the cheaper route and just do some routine engineering calculations...  but you're free to fund any experiments you like.

[Someone]

So is the demand for < 0.5 picosecond jitter in the DAC clock absurd, or have I made an error in my reasoning above?

Your maths is sound, assuming thats the measurement of the jitter at the analog sampling. Along the way from the clock source there are other components that will all add noise so its a good idea to have some margin beyond whats strictly required but the advice you are quoting is as you suggest beyond the point of theoretical effect.

[wraper]

<0.5ns  Bullshit.

passable

around 0.5us maybe.

will sound like junk

around 0.5ms yes.

, I doubt anyone will listen this noise generator. 0.5ms, really? Hard to day, but probably it would sound similar to 3 bit resolution @ 1 kHz sample rate.

[tszaboo]

That jitter is not even related to the samples themselves but to the bits. Now, you have a 24 bit 192khz stereo system, all the data goes through I2S, that is about 9 megabit/s. That 0.5 ps jitter per bit suddenly becomes 5ppm of your bit. If you take the noise analogy, -106dB, almost audible range, so I would say, he is right.
It is actually not as simple. I have the impression, that engineers oversimplify audio all the time. Jitter is changing the frequancy of the signal, so you cannot make that simple calculations.
Remember, it is for frequency. Brain does fancy stuff with frequency, that is how you locate stuff only by sound. If one of your ears receive a changing frequency, while the other one a stable one, your brain translates this, that the object emitting the sound is moving.
If you want to analise an audio system, dont ever forget, that the full signal chain includes the human at the end, with two ears, and with a brain that does fancy DSP stuff. I think every audio system designer makes this mistake, that is why we cannot come close to live music with recordings.

[dmills]

This is subtle, mainly because there are at least two separate issues.

Clearly the I2S stream must have sufficiently low jitter on the SClk (and probably also the LRClk) to still make setup and hold reliably, this should be obvious and non controversial, given Sclk at a few MHz, this imposes a limit at maybe a hundred ns or so if the I2S is to be correctly decoded, but providing it is satisfied, bits is bits.

The other (And far more debatable) issue is (Depending on architecture) jitter on the LRClk or MClk depending on which one is the critical clock for converter timing, here the standard math for jitter Vs SNR applies, and the nasty case is usually a DS modulator running at 24MHz or so (A baseband R2R converter at 48K obviously has rather lower sensitivity, but other horrible issues). Some of the early delta sigma parts were notoriously sensitive (IIRC it was all that single bit stuff that was briefly popular until Stanley Lipshitz pointed out the emperors lack of clothes in his inimitable math heavy style).

You need to see sampled systems as mixers, and in the case of a delta sigma design as a mixer that folds the reciprocal mixing products down into the baseband, which is what makes these problematic from this perspective ((sin x)/x limits it, but still).

Interestingly there have been proper studies done showing that it is the phase noise distribution as much as total jitter that matters with close in PN being a much bigger issue then PN that is more then a few hundred Hz away from the clock, IIRC it was an AES paper that had the details.

Given the limitations of real microphones in real rooms recorded thru real mixing desks on real recorders (And the somewhat more severe issues with most listening rooms) a DAC for use in the replay chain does NOT need an ENOB greater then 16-18 or so. Hell a microphone impedance converter (Never mind the diaphragm) is struggling to make more then 120dB dynamic range or so off a standard 48V rail.
 
Jitter is one of those things where if you ignore it completely will bite you in the arse, but if you go for an VCXO in the loop rather then just using the recovered mclk from the line receiver and practise general good RF design there is no reason IMHO for it to be a serious problem for an audio converter. It is however the audiophiles favourite bogeyman mostly because it is tricky to measure directly unless you have an RF lab available, ideally with a signal source analyser. There are however ways to measure it indirectly given a sufficiently better measurement converter, but that can itself be quite a big ask.

Regards, Dan.

[BrianHG]

<0.5ps Bullshit.
<0.5ns  Bullshit.
around 0.5us maybe.
around 0.5ms yes.

What kind of lousy DAC has this author been using?

Or in fact you know nothing? How about learning from the experts:
http://cds.linear.com/docs/en/design-note/dn1013f.pdf
ps of jitter is right on the ballpark for a high quality clock source when you consider distribution and noise.

A/B or GTFO

Or go the cheaper route and just do some routine engineering calculations...  but you're free to fund any experiments you like.

We are talking about a 44.1KHz clocked resistor ladder 16 bit audio dac.  This is not high speed by any means.  Having the resistors in the audio dac randomly switch in 0.5ns early or late once every single clock will not be seen or heard at all.  In fact, even 5 or 50 ns early or late jitter once every 44.1 thousandths of a second wont be heard by anyone.  Even with the quality of audio equipment I have, I could not tell the difference.  Even vinyl can't come close to PS refinement & top audio gurus claim this physical medium to be superior.  Under pristine side-by-side comparison, maybe one could hear the difference between 50ns jitter and a far superior 5ns jitter window of error once every 44.1 thousandth of a second, but, I bet you are not one of those who could.

Do not be confuse with the limitation and internal functionality of 1 bit PCM dacs with internal oversampling like what is mentioned in the author's document.  He is dealing with a multitude of effects and the means of how the DAC he is using uses a super-high speed multiple of the source clock synthesizing an audio bandwidth signal from a super fast 1 bit dac.  In my book, such problems should be handled by the DAC internally since they multiply the source clock anyways.

During high speed data transmition, in the megabits range for HDaudio, and clock recovery from said source, yes, a clean clock is required for error free recovery.  But, divide that down to the original 44100hz and feed that parallel data into a true R2R ladder DAC, on that latch clock, if there is a 0.5ns early/late arrival jitter, once every 44100 of a second at a time, no one will hear the difference even if that error was 10x, or 100x.

[wraper]

During high speed data transmition, in the megabits range for HDaudio, and clock recovery from said source, yes, a clean clock is required for error free recovery.  But, divide that down to the original 44100hz and feed that parallel data into a true R2R ladder DAC, on that latch clock, if there is a 0.5ns early/late arrival jitter, once every 44100 of a second at a time, no one will hear the difference even if that error was 10x, or 100x.

Why do you assume that jitter happens once in a second? What if every sample? R2R audio DACs are basically nonexistent nowadays.

In my book, such problems should be handled by the DAC internally since they multiply the source clock anyways.

And what the paper says:

P.S.: With the DAC: PCM1792 this reclocking is not needed because it has been implemented into
the chip itself! The only precondition is that the bit clock (BCK, pin 6) has as little jitter as possible so
put the Xtal oscillator on 11.2896 MHz close to the DAC, at least in the same cabinet.

[rachaelp]

We are talking about a 44.1KHz clocked resistor ladder 16 bit audio dac.  This is not high speed by any means.  Having the resistors in the audio dac randomly switch in 0.5ns early or late once every single clock will not be seen or heard at all.  In fact, even 5 or 50 ns early or late jitter once every 44.1 thousandths of a second wont be heard by anyone.  Even with the quality of audio equipment I have, I could not tell the difference.  Even vinyl can't come close to PS refinement & top audio gurus claim this physical medium to be superior.  Under pristine side-by-side comparison, maybe one could hear the difference between 50ns jitter and a far superior 5ns jitter window of error once every 44.1 thousandth of a second, but, I bet you are not one of those who could.

If you have jitter on your sample clock then you are sampling in the wrong place and it affects the value you read. 50ns will have an effect, most noticable at higher frequencies.

Human hearing has a dynamic range of around 120dB and is most sensitive over the 2-4KHz range. So if you take 4KHz and your 50ns example, you'd actually be reducing the effective number of bits from your 16-bit ADC/DAC to about 12-bits because of the sampling inaccuracies. You will hear the difference between this and 5ns error. You'll also likely hear errors in higher frequency content at lower jitter levels so really to give a comfortable margin you might want say 0.5ns jitter max for a 16-bit ADC/DAC.

So what's the point of having better jitter? Well 16-bits doesn't necessarily give the full dynamic range you can hear so as you increase your bits per sample your jitter on your sample clock needs to improve. 24-bit ADC/DAC are common place and so the jitter needs to be a lot less when using these. I'm not saying we can hear that level, you probably don't actually need to be going much past 18 to 20-bits before its all a bit academic from just listening to it but there is also another reason why we use higher bit depths and tighter jitter specs in ADC/DAC in pro-audio equipment which is because in large systems the signal can be converted numerous times and errors add up so we make it a lot better than is normally audible so that once it's been converted a few times its still good.

Best Regards,

Rachael

[madires]

The question should be: what is the time resolution of the human sense of hearing for determining the position of an audio source?

[BrianHG]

During high speed data transmition, in the megabits range for HDaudio, and clock recovery from said source, yes, a clean clock is required for error free recovery.  But, divide that down to the original 44100hz and feed that parallel data into a true R2R ladder DAC, on that latch clock, if there is a 0.5ns early/late arrival jitter, once every 44100 of a second at a time, no one will hear the difference even if that error was 10x, or 100x.

Why do you assume that jitter happens once in a second? What if every sample? R2R audio DACs are basically nonexistent nowadays.

In my book, such problems should be handled by the DAC internally since they multiply the source clock anyways.

And what the paper says:

P.S.: With the DAC: PCM1792 this reclocking is not needed because it has been implemented into
the chip itself! The only precondition is that the bit clock (BCK, pin 6) has as little jitter as possible so
put the Xtal oscillator on 11.2896 MHz close to the DAC, at least in the same cabinet.

Not once per second, once per sample clock at the sample rate.  The system clock, today usually being in the double digit MHz range, usually has a crystal somewhere behind it all and over the average, it should always be way outside the performance of any human ear unless something is designed or wired really wrong.  Now if you multiply tiny accumulative worst case errors at that MHz clock frequency which all add together divided down to the audio sample rate making the 44k clock deviate in the high ns region, then something is seriously wrong with you clock circuitry.  Such larger accumulative errors starting in the ps going down to the audio band is a sign of problems like poor power supply regulation for you clock oscillator, or, if you have a PLL tuning source clock, that tuning signal have a low frequency modulation.

I don't like that the author of the document seems to imply that if we have an audible difference in audio because the sample clock error at 44k has a large enough error to hear the difference, well, we can multiply/divide up that error among all the consecutive source MHz clock frequency range and call it a sub pico-second error of each individual MHz clock cycle.  You are no longer identifying where this accumulated error is coming from within your system.

As for the PCM1792, it's not a DAC I would use, though it is specked really high and should be fairly immune from some random high frequency jitter unless that jitter is really a low frequency jitter in disguise being divided up into a high frequency clock as I described above.


And, most of us cannot hear the difference between around 14 bit and 16 bit audio.  12 and 14 bit, yes, it's getting easier to tell under the correct source audio conditions, namely NOT modern music recordings mastered to full volume always on cheap audio gear.

[bktemp]

And what the paper says:

P.S.: With the DAC: PCM1792 this reclocking is not needed because it has been implemented into
the chip itself! The only precondition is that the bit clock (BCK, pin 6) has as little jitter as possible so
put the Xtal oscillator on 11.2896 MHz close to the DAC, at least in the same cabinet.

Can anybody find a reference to that statement in the PCM1792 datasheet?
I can only find the requirement of SCK = 128/192/256/384/512 or 768 x fs, similar to most other DACs.

[BrianHG]

I guess what we are boiling down to is:  What is the spectrum of that <0.5ps jitter of your >10MHz clock.  If all that jitter is concentrated below 15, or 10 Khz, even though your source clock is way in the >10MHz, it will have that accumulated effect, but, now, at 44k, the deviation error at each clock cycle isn't 0.5ps, it's a much larger accumulated error.  So, I can no longer call this a 0.5pf jitter.  Now, if the 0.5ps jitter's spectrum is broad, or, white all the way to the >10MHz clock, you wont have anything audible with your 44KHz clock.

[BrianHG]

And what the paper says:

P.S.: With the DAC: PCM1792 this reclocking is not needed because it has been implemented into
the chip itself! The only precondition is that the bit clock (BCK, pin 6) has as little jitter as possible so
put the Xtal oscillator on 11.2896 MHz close to the DAC, at least in the same cabinet.

Can anybody find a reference to that statement in the PCM1792 datasheet?
I can only find the requirement of SCK = 128/192/256/384/512 or 768 x fs, similar to most other DACs.

Now that TI have replaced the part number, here it is:
http://www.ti.com/product/pcm1792a/description

Middle of page 15, Table 1, 256fs/44.1Khz in the table says 11.2896 Mhz source clock.
It's also used in DSD format, page 2 on maximum clock frequency 2/3rd of the way down.

[alexanderbrevig]

Jitter has become an umbrella term and for this conversation to be fruitful I think someone should define which we are talking about. When you USB audio card clicks so loud you fear for your drivers... you will hear it.
Some people call this jitter, and they are not entirely wrong. I call it packet loss.

[BrianHG]

And what the paper says:

P.S.: With the DAC: PCM1792 this reclocking is not needed because it has been implemented into
the chip itself! The only precondition is that the bit clock (BCK, pin 6) has as little jitter as possible so
put the Xtal oscillator on 11.2896 MHz close to the DAC, at least in the same cabinet.

Can anybody find a reference to that statement in the PCM1792 datasheet?
I can only find the requirement of SCK = 128/192/256/384/512 or 768 x fs, similar to most other DACs.

Now that TI have replaced the part number, here it is:
http://www.ti.com/product/pcm1792a/description

  LOL, according to TI own data sheet, they say to use their PLL1700 clock generators as an ultra low jitter clock source for this DAC.  Now, guess what the specked jitter on the PLL1705/PLL1706 chip is?  50ps, not 0.5ps.

[BrianHG]

Jitter has become an umbrella term and for this conversation to be fruitful I think someone should define which we are talking about. When you USB audio card clicks so loud you fear for your drivers... you will hear it.
Some people call this jitter, and they are not entirely wrong. I call it packet loss.

We are looking at Page 2 of the linked document in the OP's opening message.  It's dealing with the DAC source clock and it's minute effects on the audio output, not data errors or missed packets.

[bktemp]

And what the paper says:

P.S.: With the DAC: PCM1792 this reclocking is not needed because it has been implemented into
the chip itself! The only precondition is that the bit clock (BCK, pin 6) has as little jitter as possible so
put the Xtal oscillator on 11.2896 MHz close to the DAC, at least in the same cabinet.

Can anybody find a reference to that statement in the PCM1792 datasheet?
I can only find the requirement of SCK = 128/192/256/384/512 or 768 x fs, similar to most other DACs.

Now that TI have replaced the part number, here it is:
http://www.ti.com/product/pcm1792a/description

Middle of page 15, Table 1, 256fs/44.1Khz in the table says 11.2896 Mhz source clock.
It's also used in DSD format, page 2 on maximum clock frequency 2/3rd of the way down.

But there is nothing about reclocking in the datasheet.
What happens if somebody uses a freerunning clock for SCK that is not locked to the audio source? It will not be exactly 256x fs.
The audio samplerate will be slightly faster or slower than the samplerate required by the DAC for doing its oversampling. The TI datasheet does not discuss this condition, but some other DACs so: They will replicate or discard one full input sample. If that happens, the resulting distortions in the audio signal are much worse than the jitter introduced by a not perfect system clock.

Therefore I would call the statemant regarding reclocking inside PCM1792 bullshit.

[BrianHG]

Therefore I would call the statemant regarding reclocking inside PCM1792 bullshit.

I think the quote of the author's 'reclocking' term might mean just a simple internal PLL in the DAC to achieve it's internal master reference clock which is way above 11MHz  (not specified by TI as it is internal secret sauce, but needed for a good high resolution high quality 1 bit PWM output).  The PCM1792 clearly cannot correct for missing or added samples due to word alignment errors lost in incorrectly timed data input.

If the author is doing as you say, I then need to question everything is his document as he is clearly making a fundamental mistake.  Especially when he is using a cheap crystal oscillator.  Something is beginning to smell fishy.

Especially when TI, who made the DAC themselves, say that their own precision 50ps jitter rated clock generating chip should be best used with their TOP audio dac and say nothing about improving the source clock's performance by 2 orders of magnitude.  If fact, if you read the dac's allowable clock jitter spec, you are allowed above 4ns of jitter, almost another 2 orders of magnitude worse to make the DAC run error free.

[f5r5e5d]

http://thewelltemperedcomputer.com/KB/BitPerfectJitter.htm seems good,

about halfway down actual peer reviewed human listening test paper's results are shown 10s-100s of ns with random jitter, music

maybe few ns with structured jitter and test tones


a common confusion is that Adams, Dunn calculate jitter degrading S/N at the 16 bit lsb level for 20 kHz full amplitude sine - pure engineering calc - not a listening test verified number

[bktemp]

Therefore I would call the statemant regarding reclocking inside PCM1792 bullshit.

I think the quote of the author's 'reclocking' term might mean just a simple internal PLL in the DAC to achieve it's internal master reference clock which is way above 11MHz  (not specified by TI as it is internal secret sauce, but needed for a good high resolution high quality 1 bit PWM output).  The PCM1792 clearly cannot correct for missing or added samples due to word alignment errors lost in incorrectly timed data input.

That's why I asked for any reference for that in the datasheet.
If they had added such a nice feature, you can be sure the marketing department would have put the information on the first page of the datasheet.
Since there is no mention of such a feature anywhere in the datasheet (at least I couldn't find it), especially since this feature would make the need for a samplerate dependend system clock unnecessary, I doubt PCM1792 is any different in that aspect than any other 1 or multibit delta-sigma DAC.
PCM1792 seems to use a combination of a conventional (R2R?) DAC and a delta-sigma DAC to achieve the high resolution with a low jitter tolerance. Therefore it doesn't need a super high oversampling ratio and probably uses the system clock directly for the DAC.

If the author is doing as you say, I then need to question everything is his document as he is clearly making a fundamental mistake.  Especially when he is using a cheap crystal oscillator.  Something is beginning to smell fishy.

I have seen this mistake in several high-end DAC circuits build by audiophile "experts". They try to cover all problems of consumer DACs, but at the end they get the fundamental stuff wrong.