Digital Audio Jitter explained in simple terms

amirm · Jan 21, 2012

I got tired for explaining jitter for the 100th times and last year decided to write an article on it for Widescreen Review Magazine. Now that the issue has been out for a while, I converted it to html and post it on the web site: Digital Audio: The Possible and Impossible.

As usual, let me know if you see any typos and of course, any questions you might have.

Here is the intro:

"Pop quiz: Which of these statements would you say is true?
1. If you change the HDMI cable between your Blu-ray player and AVR/Processor, the analog audio output can change.
2. If you turn off the display and video circuits in your Blu-ray player or AVR/Processor, the analog audio output can change.
3. If you have a DAC with USB and S/PDIF inputs, changing from one to the other can change the analog output.
4. If you change from HDMI input to S/PDIF on your AVR or Processor, the analog output can change."

Johnny Vinyl · Jan 21, 2012

Thanks so much for that article Amir! This is the type of writing I appreciate as a non-technical person. So if I read correctly, I would be better off using a S/PDF cable going from my BDP to my AVR, as opposed to HDMI. But what of an analog connection (if available of course)? Is this preferred over S/PDF?

Pop Quiz answers

o)

1. NO
2. YES
3. YES
4. YES

Ronm1 · Jan 21, 2012

John72953 said:
But what of an analog connection (if available of course)? Is this preferred over S/PDF?

I'll bite, the simple answer is, if DAC's are better at the source, yep. If not, nope. Course we could make it more complicated, but then

JonFo · Jan 21, 2012

Amir, good article.

However, we need to clarify that all this applies to LPCM data, such as the typical CD data stream over SPDIF.

For BluRay movie and audio soundtracks encoded with packetized protocols such as Dolby TrueHD or DTS-MA (or heck even Dolby AC3 and legacy DTS), the transfer of these error-corrected high-level protocols to the AVR will result in complete immunity to cable or interface clocking variations.

So the answer to #1 and #2 above would be: there is no difference in analog output when using non-LPCM sources.

Bitstreaming packetized protocols between BluRay and an AVR results in the AVR doing all the protocol unwrapping and decoding then generating the LPCM streams for the DAC inside the AVR using the same master clock the DACs will use, therefore reducing jitter possibilities to their absolute minimums. Ideally, there is none, as source and DAC are slaved to the same clock.

So for all movie and most music content available on BluRay, HDMI is just fine from an audio standpoint.

CD players and other LCM sources with no clock-synch, totally agree, Jitter is a challenge.

JonFo · Jan 21, 2012

The benefits of having the AVR/Pre-Pro do the packet decoding and internally generating the LPCM signals can also apply to packetized audio formats, such as FLAC.

If your AVR can pull FLAC files from a DLNA server and do internal decoding, this will give you total jitter immunity from cables, sources, etc.

Most modern AVRs are DLNA renderers with at least stereo 16/44 FLAC support (a few get up to 24/96), so now that many people are using music servers with purchased tracks or rips of their CD collection, they can minimize jitter effects by using the AVR as the renderer.

So on top of increasing the audio fidelity, this approach lowers complexity and cost regarding external rendering boxes and associated cabling.

amirm · Jan 21, 2012

JonFo said:
Amir, good article.

Thanks

.

However, we need to clarify that all this applies to LPCM data, such as the typical CD data stream over SPDIF.

For BluRay movie and audio soundtracks encoded with packetized protocols such as Dolby TrueHD or DTS-MA (or heck even Dolby AC3 and legacy DTS), the transfer of these error-corrected high-level protocols to the AVR will result in complete immunity to cable or interface clocking variations.

Actually, this makes no difference at all! I should have added it to the list of items on the pop quiz

.

Everything you describe is true as far as getting the bits to the receiver. Once there, a DSP decodes that stream into PCM samples. Now what? What clock do you use to output them? Answer is that the HDMI video clock will be used just the same as if you had used PCM input! Otherwise, all the sync issues and such that I mentioned in the article applies.

Bitstreaming packetized protocols between BluRay and an AVR results in the AVR doing all the protocol unwrapping and decoding then generating the LPCM streams for the DAC inside the AVR using the same master clock the DACs will use, therefore reducing jitter possibilities to their absolute minimums. Ideally, there is none, as source and DAC are slaved to the same clock.

As I mentioned, that is not the way it works or your audio will drift relative to video. The only way to make sure that doesn't happen is to lock to the video clock used on HDMI. And locking means deriving the clock for the decoded bitstream from HDMI.

So for all movie and most music content available on BluRay, HDMI is just fine from an audio standpoint.

CD players and other LCM sources with no clock-synch, totally agree, Jitter is a challenge.

Due to the fact that lossless audio streams are not supported over HDMI, you are forced to use that interface regardless for Blu-ray. In that case, I would try to and find a low jitter system by reading reviews if you can. Otherwise, for movies I would not sweat it and use HDMI regardless.

amirm · Jan 21, 2012

JonFo said:
The benefits of having the AVR/Pre-Pro do the packet decoding and internally generating the LPCM signals can also apply to packetized audio formats, such as FLAC.

If your AVR can pull FLAC files from a DLNA server and do internal decoding, this will give you total jitter immunity from cables, sources, etc.

Most modern AVRs are DLNA renderers with at least stereo 16/44 FLAC support (a few get up to 24/96), so now that many people are using music servers with purchased tracks or rips of their CD collection, they can minimize jitter effects by using the AVR as the renderer.

This does work and does put the AVR/DAC in the position of being the master. However, use of networking on your device will likely increase sources of jitter. Networking usually implies a full blown operating system and that means a ton of CPU traffic which can create a noisier environment for the decoder clock. You may actually be better off using an async USB feeding the DAC/AVR over S/PDIF than this method.

So on top of increasing the audio fidelity, this approach lowers complexity and cost regarding external rendering boxes and associated cabling.

I think anything that includes networking increases complexity, not reduce it

. But I get your point.

Thanks for the thoughtful responses by the way. I am half way through part II of that article and while I had covered the BD scenario, I had not included the networked scenarios in there. I will add that

.

JonFo · Jan 22, 2012

amirm said:
Thanks .

Re: packetized protocols - Actually, this makes no difference at all! I should have added it to the list of items on the pop quiz .

Everything you describe is true as far as getting the bits to the receiver. Once there, a DSP decodes that stream into PCM samples. Now what? What clock do you use to output them? Answer is that the HDMI video clock will be used just the same as if you had used PCM input! Otherwise, all the sync issues and such that I mentioned in the article applies.

OK, now I’m confused, as most pre-pros/AVRs whose schematics I’ve looked at (mostly Denons) have separate clocks for audio.

If what you describe is actually true, then TrueHD and DTS-MA could NEVER be accurate due to varying clocks. Not something I’ve ever heard about or experienced in practice. Steve Wilsons Grace for Drowning BluRay (5.1 Dolby TrueHD 24/96) is the most accurate recording I have (of 100+ SACD/DVD-A using clock-synched DenonLink players). So my experience as well as my review of the Denon AVP-A1HD schematics tell me that decoded packetized audio has its own clock in this pre-pro.

amirm said:
As I mentioned, that is not the way it works or your audio will drift relative to video. The only way to make sure that doesn't happen is to lock to the video clock used on HDMI. And locking means deriving the clock for the decoded bitstream from HDMI.

Due to the fact that lossless audio streams are not supported over HDMI, you are forced to use that interface regardless for Blu-ray. In that case, I would try to and find a low jitter system by reading reviews if you can. Otherwise, for movies I would not sweat it and use HDMI regardless.

The video is reclocked and timed in the scaler in many pre-pros, as it can (and needs to due to audio DSP processing) apply lip-synch delays to video or audio. So video and audio are synchronized with variable delays depending on latencies of audio OR video processing (upscaling or not, Audyssey or not, etc.).

I’m sure it’s a typo, but “Due to the fact that lossless audio streams are not supported over HDMI”, is incorrect. DTS-MA and TrueHD are indeed lossless packetized protocols that bitsream over HDMI.

For movies, and modern BluRay music disc such as the Steve Wilson recording mentioned above, bitstreaming over HDMI is the only way to get the best audio results IMO.

I could be all wet about the clocking, so pointers to examples of measured issues with internally decoded audio streams would be welcome.

amirm · Jan 22, 2012

JonFo said:
OK, now I’m confused, as most pre-pros/AVRs whose schematics I’ve looked at (mostly Denons) have separate clocks for audio.

They ALL have separate "clocks." Question is the frequency of said clock. We can agree that the clock rate changes to match the sampling rate at least. Yes? Then we are agreeing that the fact that there is a clock, does not mean that it is fixed and master of all things. Look at this diagram from the nice Article Don post a while back in EDN: http://www.edn.com/article/520241-A...php?cid=NL_Newsletter+-+Electronic+News+Today

You see that there is a crystal connected to the PLL. PLL's job is then to vary said clock to match the input rate. Here is a zoomed version of that:

If what you describe is actually true, then TrueHD and DTS-MA could NEVER be accurate due to varying clocks.

Accurate in what respect? That the samples change? No. The samples are always recovered. The fact that the timing changes does indeed mean that it can never recreate the original analog signal. This is true of all practical digital systems. As soon as we go in and out of analog, we lose precision. Jitter is only one contribution to that. Now, one hopes that the contributions here are below our hearing ability but from a pure measurement point of view, it is there and as such, there is no such thing as "lossless" audio. It is only lossless while you are in digital domain.

Not something I’ve ever heard about or experienced in practice. Steve Wilsons Grace for Drowning BluRay (5.1 Dolby TrueHD 24/96) is the most accurate recording I have (of 100+ SACD/DVD-A using clock-synched DenonLink players). So my experience as well as my review of the Denon AVP-A1HD schematics tell me that decoded packetized audio has its own clock in this pre-pro.

Now you are talking about a proprietary exception. DenonLink does indeed attempt to solve this problem by having the target be the master. If feeds the DAC clock up stream to their player, forcing it to adjust the video clock such that jitter is reduced. Pioneer has a similar solution.

HDMI actually has a spec for this that allows the target to be in control. Problem is, few players support it and even if they did, there is no telling what they do when asked to slow down or speed up.

The video is reclocked and timed in the scaler in many pre-pros, as it can (and needs to due to audio DSP processing) apply lip-synch delays to video or audio. So video and audio are synchronized with variable delays depending on latencies of audio OR video processing (upscaling or not, Audyssey or not, etc.).

That's true but I wrote an article to cover how the technology works in general, not in the exceptional case of one system. The fact that DenonLink exists and does what it does, is ample proof that without it the system has the problem I mentioned. And that the mere fact of pushing a bit stream into an AVR does nothing to solve this problem.

I’m sure it’s a typo, but “Due to the fact that lossless audio streams are not supported over HDMI”, is incorrect. DTS-MA and TrueHD are indeed lossless packetized protocols that bitsream over HDMI.

Yes, it was a typo. I will fix.

For movies, and modern BluRay music disc such as the Steve Wilson recording mentioned above, bitstreaming over HDMI is the only way to get the best audio results IMO.

For just about everyone who doesn't have these proprietary, matched player and AVRs, that is not true as I have explained.

treitz3 · Jan 22, 2012

As a new member looking to learn more about the digital realm that touch at the very heart of topics such as this, I thank you for your contribution. Very nice, well written and educational article. I love picking at the brains of those who have mastered the one thing I would like to learn about. You just so happen to be one of those folks. Thank you.

ack · Jan 23, 2012

Amir - thanks for this excellent effort in the article; it was very easy to follow... A couple of questions if I may:

How does the receiver know/determine the zero crossing?
You seem to dismiss the benefit of an input buffer, and make the case that the DAC always follows the input... Fine, but can you explain then how master/slave designs work and how they might differ from the typical architecture? Like Wadia's CloqLink, or the SpectralLink? What problems to they solve and to what degree? If not clear, I am talking about architectures that [claim to] slave the sender to the receiver's clock. What are the drawbacks?

Thanks

amirm · Jan 23, 2012

ack said:
Amir - thanks for this excellent effort in the article; it was very easy to follow...

My pleasure

.

[*]How does the receiver know/determine the zero crossing?

Using a zero-crossing detector

. There are many approaches to it depending on the requirements for the circuit (speed, etc). Here is a trivial/cheap one in the Wiki:

[*]You seem to dismiss the benefit of an input buffer, and make the case that the DAC always follows the input... Fine, but can you explain then how master/slave designs work and how they might differ from the typical architecture? Like Wadia's CloqLink, or the SpectralLink? What problems to they solve and to what degree? If not clear, I am talking about architectures that [claim to] slave the sender to the receiver's clock. What are the drawbacks?

The problem they solve is what I stated. If you let the source be the master of DAC clock, then you have to resort to heroic moves to suppress jitter. If you abandon industry standard interconnects, you can indeed solve this problem by letting the external DAC to be the master, not the source. That is what CloqLink does. Put another way, this is not a hard problem to solve as a matter of electronics and computer science. It only becomes hard if you have to make current broken architectures (in this regard) work. Asynchronous USB attempts to do the same using a PC as the source.

DonH50 · Jan 23, 2012

Note that depending upon how it is clocked, a master/slave flip-flop may do nothing to alleviate clock jitter. it will provide a cleaner digital signal by providing more time to regenerate the signal levels. (Not sure if this is relevant; I did not read the whole thread, sorry.)

As Amir says, the real key is to take the source clock out of the picture and use an independent clocking scheme.

microstrip · Jan 23, 2012

DonH50 said:
Note that depending upon how it is clocked, a master/slave flip-flop may do nothing to alleviate clock jitter. it will provide a cleaner digital signal by providing more time to regenerate the signal levels. (Not sure if this is relevant; I did not read the whole thread, sorry.)

As Amir says, the real key is to take the source clock out of the picture and use an independent clocking scheme.

This has been done before - late 90s if I am not mistaken - for CD playback. I can not remember the brand any more, but some people had the DAC with a master clock slightly faster than the maximum allowed tolerance for CD playback and a memory buffer to compensate for it. But it was not accepted as a perfect DAC. The increase in speed would not be audible for consumer audio playback.

DonH50 · Jan 23, 2012

Actually, they wouldn't need a higher-frequency clock, just a big enough buffer. At least CDs are finite in size; other sources are not. Elasticity buffers and handshaking protocols in digital transmission systems handle the problem, but AFAIK there is no equivalent skip code in the digital audio data stream (though I admit I have not looked for it). An asynchronous DAC and buffer will work, with the caveat that if you use a streaming source (essentially "infinite" data) you could eventually exceed the buffer's capacity. An interesting solution would be to use a SSC scheme with a deviation that helps reduce the impact of finite FIFO (buffer) size.

I wonder if anybody would notice a skipped word in a 192 kS/s data stream?

fas42 · Jan 23, 2012

microstrip said:
This has been done before - late 90s if I am not mistaken - for CD playback. I can not remember the brand any more, but some people had the DAC with a master clock slightly faster than the maximum allowed tolerance for CD playback and a memory buffer to compensate for it. But it was not accepted as a perfect DAC. The increase in speed would not be audible for consumer audio playback.

Not talking about the Genesis Digital Lens, perhaps?

Frank

fas42 · Jan 23, 2012

DonH50 said:
Actually, they wouldn't need a higher-frequency clock, just a big enough buffer. At least CDs are finite in size; other sources are not. Elasticity buffers and handshaking protocols in digital transmission systems handle the problem, but AFAIK there is no equivalent skip code in the digital audio data stream (though I admit I have not looked for it). An asynchronous DAC and buffer will work, with the caveat that if you use a streaming source (essentially "infinite" data) you could eventually exceed the buffer's capacity. An interesting solution would be to use a SSC scheme with a deviation that helps reduce the impact of finite FIFO (buffer) size.

I wonder if anybody would notice a skipped word in a 192 kS/s data stream?

As I've mentioned elsewhere, all you really need is intelligent monitoring of the musical data for what is effectively silence. Skip here as needed, with zero audible glitching.

Frank

DonH50 · Feb 8, 2012

Good luck getting a consensus on what constitutes "effectively silence"...

fas42 · Feb 8, 2012

DonH50 said:
Good luck getting a consensus on what constitutes "effectively silence"...

Actually, that shouldn't be too difficult, Don. People have different sensitivies to audible sound, so when someone newly acquires a system with such a capability there could be a simple calibration routine as part of the setup procedure. The system plays pink noise, whatever, at a certain volume, with certain spectrum content, over various ranges and levels, and the listener indicates when such is audible or not. A happy compromise is reached, which could be readjusted as necessary ...

Frank

thedon1989 · Jul 2, 2012

USB or SPDIF

amirm said:
I got tired for explaining jitter for the 100th times and last year decided to write an article on it for Widescreen Review Magazine. Now that the issue has been out for a while, I converted it to html and post it on the web site: Digital Audio: The Possible and Impossible.

As usual, let me know if you see any typos and of course, any questions you might have.

Here is the intro:

"Pop quiz: Which of these statements would you say is true?
1. If you change the HDMI cable between your Blu-ray player and AVR/Processor, the analog audio output can change.
2. If you turn off the display and video circuits in your Blu-ray player or AVR/Processor, the analog audio output can change.
3. If you have a DAC with USB and S/PDIF inputs, changing from one to the other can change the analog output.
4. If you change from HDMI input to S/PDIF on your AVR or Processor, the analog output can change."

Considering connecting DAC using USB or SPDIF of my PC. DAC not bought yet. Which output has less jitter or more importantly less jitter effects on sound from a DAC connected to the PC?

Digital Audio Jitter explained in simple terms

Banned

Member Sponsor & WBF Founding Member

Member Sponsor

Well-Known Member

Well-Known Member

Banned

Banned

Well-Known Member

Banned

Super Moderator

VIP/Donor & WBF Founding Member

Banned

Member Sponsor & WBF Technical Expert

VIP/Donor

Member Sponsor & WBF Technical Expert

Addicted To Best

Addicted To Best

Member Sponsor & WBF Technical Expert

Addicted To Best

New Member

Similar threads