• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Digital Audio Jitter Fundamentals

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,386
Location
Seattle Area
Author, our resident expert DonH50

Jitter 101
Jitter is yet another one of those things not terribly hard to understand but with lots and lots of nuances and seemingly hidden details. To begin, let’s define some terms, starting with aperture time.

upload_2017-9-12_22-46-57.png


Figure 1 shows a signal we want to sample. It moves fastest (has the highest slew rate) at the center crossing. Zooming in, the time it takes the signal to change by 1 least-significant bit (lsb) in amplitude is the aperture time (tap). If we sample anywhere within this time window, the output will be the same code (assuming the amplitude starts and ends on a threshold). If we fall outside the window, the next code lower or higher will be output. For a sine wave of amplitude A and frequency f, the maximum slew rate is 2*pi*f*A (the magnitude of the first derivative with respect to time). For an N-bit ADC or DAC and that same sine wave input, the aperture time is 1/[(2^N)*pi*f] (the amplitude ratios out of the equation). Since it is the time required for the signal to pass through 1 lsb, the clock frequency (sampling rate) does not enter into the equation. Figure 2 shows the aperture time window for various frequencies and resolutions.

upload_2017-9-12_22-47-28.png


Time jitter is variation in the sampling time, which results in a corresponding change in sampled amplitude. Jitter that exceeds the aperture time causes the wrong codes to be output, reducing the ADC’s (or DAC’s) performance. The jitter can be random or deterministic (i.e. determined by some signal, be it the input, clock, power supply ripple, DSP, and/or some combination of those or other sources, including the radio transmitter down the road). Random normal (Gaussian) jitter with standard deviation equal to the aperture time causes about 8 dB reduction in SNR (a little over 1 bit of resolution loss).

Random jitter is just noise. It degrades (reduces) the SNR but does not add any nasty tones to the signal. It comes from three primary sources:

1. Thermal noise. Even just sitting there, the electronic particles in a resistor, wire, whatever are randomly moving around and bumping into each other. This creates noise, and the hotter it gets the farther and faster they move, creating even more noise. It is very broadband, extending (theoretically) into the THz (10^12) region. Real systems have filtering, intentional or not, that greatly limit the thermal noise bandwidth. This noise causes the sample time to vary a bit, and jitter is one result.

2. Ever look real closely at the water from a tap? It does not flow smoothly up close, even though from a couple of feet away it looks like a smooth stream. At any temperature above absolute zero, the electron flow that makes up current is not a steady stream, either. The electrons jump about randomly, in starts and stops, even though the overall trend is in one direction (at a given time). This is shot noise and happens whenever current flows. It is also very broadband.

3. The last noise source I’ll describe here is flicker noise, often called 1/f noise due to the 1/frequency characteristic it’s amplitude takes over much of it’s frequency range. (In fact, the slope can be 1/f^2, 1/f^3, etc. – and various combinations across the spectrum.) Flicker noise is caused by traps – places electrons (and holes) get “caught” and held by defects in materials (like wires, capacitors, resistors, etc.) The amount of time they get “held” varies and is random, but relatively long compared to other noise sources. This means it occurs primarily in the 1 to perhaps 10 Hz or so band for most audio components. (FETs are actually worse than bipolar transistors for flicker noise for various reasons a bit too esoteric to go into here.) While it can (and so it does) modulate the sampling circuits directly, it also causes phase modulation in the clock circuits (phase-locked loops, PLLs) used in data converter systems.

Deterministic jitter is much more insidious and I personally feel is the primary jitter component causing audible distortion. Deterministic means it is determined by some signal, and that is often not a signal we want in our system. These unwanted signals may not be related to the signal, and thus spurs from them really stand out to our ears. Even when related to the signal, deterministic jitter can reduce performance far more than random jitter by adding spurs that are much, much larger than simple random jitter (noise) adds. Examples will come later… First, a few causes:

1. Limited system bandwidth causes some deterministic jitter in all digital systems. In effect, limited bandwidth causes the sampling point to vary with the data (signal), adding signal-dependent deterministic jitter to our systems. Blah. I’ll come back to this one…

2. All real systems have a little bit of “memory” in them in the form of charge storage. This memory (hysteresis) can be stray (parasitic) capacitance or inductance, magnetic fields, etc. This tiny bit of memory means new signals coming in get corrupted a little bit by the previous signals, again introducing deterministic jitter into our systems.

3. Coupled signals are often the hardest to screen, identify, and fix. Any signal coupled into the clock creates deterministic jitter; that is, jitter determined by the coupled signal. Power supply ripple, the DSP clock in the AVR or CD/DVD/BRD player, the actual signal, external noise (radio/TV stations, cable amplifiers, the good buddy on his CB, etc.) can all sneak in through ground or power traces or even through the air to create deterministic jitter.

To get back to (1) briefly, look at Figure 3 below, which shows a few cycles in a digital bit stream. I have shown a […0,1,0,1,0,1,1,0,1…] pattern (sort of). Limited high-frequency bandwidth does not let the alternating 0/1 patterns reach full amplitude. If we look at the zero-crossing, where the data presumably changes, the slope is a little low (the red line is tilted a bit more) than the area where the signal has the 0,1,1 pattern and has time to reach full-scale. If we zoomed in very closely we’d see the crossing time is a little different for those two points due to the different slopes (which arise from the signal starting to transition from different levels).

upload_2017-9-12_22-48-8.png


Now, the top of the next (1,1) region is not flat; it slopes down a little bit. This indicates limited low-frequency bandwidth, i.e. it is not d.c.-coupled. For many reasons, wideband data systems are rarely d.c. coupled, and thus long strings of 1’s (or 0’s) can cause this to happen. The effect is again a slightly different crossing point because the signal starts from a different point, causing a different slope.

The last red line is on a part of the signal showing overshoot, where the signal actually shoots past the top and comes back down. Overshoot can improve the switching speed, but of course this means the edge is a little faster than the other edges, and again the center crossing is a little different. Aargh!

Before deciding all is lost, note that for digital signals these effects, while real, are rarely a problem in digital audio systems. The data rates are on the low end of what’s available, and error correction and careful signal construction (using tricks like dither to keep the signal always “busy”) results in extremely low bit error rates.

However, all these effects can affect the sampling clock, whether it is derived from the signal data stream (typical) or provided as a separate signal. Random and deterministic jitter on the ADC or DAC clock does cause real, measurable errors in the signals sent to our speakers. The audibility is often debated, of course; what a shock.

I am going to split the audio portion of this discussion into a separate thread. However, before leaving this one, I want to at least mention what it takes to do jitter measurement, if nothing else to explain why just asking somebody to measure it is often unfruitful. Audio jitter is fairly easy to measure because it is fairly large (10’s of ps to ns or more). Still, it takes some sophisticated equipment. At my workplace, measuring sub-ps (and into the fs) jitter requires clean low-jitter signal sources, pattern generators, digital sampling oscilloscopes (DSOs), and a host of filters, amplifiers, and specialized equipment that let us calibrate and compensate measurement error and extract (after much processing on a $2k computer running $10k to $100k of software) the true jitter numbers. We’re talking $100k signal sources, $250k bit error rate testers (BERTs), $150k and up DSOs, and $100k’s of extra amplifiers, cables, filters, and little black (gold, actually, often with heat sinks) boxes assembled into a complex test system. Perhaps $1M in equipment plus a few man-years of development. Your audio system is much lower frequency, of course, so maybe a mere $500k or so will get by…

Stay tuned for Part 2. - Don
 

sofrep811

Active Member
Joined
Jun 4, 2016
Messages
253
Likes
319
I'm a noob in asking, so if out of line I'll come back and ask. I recently purchased my 12th different DAC for my IMac (two girls, got sick of fixing issues) and my latest DAC is a NAD 1050 D USB. Compared to several I've owned I am impressed. I have never used a USB DAC since that Jitterbug came out. I'm tempted to buy, but I can't imagine it being too sophisticated on the inside. Do you know if it works and why it works? I'm assuming it's a filter and could be a simple DIY project, because for the price it can't be doing any type of clocking?

Thanks for the great site. As a reader it's a perfect fit for me.
 

sofrep811

Active Member
Joined
Jun 4, 2016
Messages
253
Likes
319
Jitterbug. If it would offer noticeable SQ with SACD rips or true not upsampled 24/96 albums.

I've looked around and can't find the exact internals for the Jitterbug, but would like to know.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,386
Location
Seattle Area
I have tested the Jitterbug it does absolutely nothing. I will upload the full review when I get a chance. For now, here are a couple of snapshots:

i-2C3hPFv-XL.png


Green is direct. Red is through Jitterbug. This is the background noise while music is not playing. As you see, it does nothing.

And here it is with a test tone:

i-Xmb2tm3-XL.png


As you see, no difference at all.

Stereophile made their measurements with the same results (no difference to speak of).

So I say save your money for something else. :)
 

Cosmik

Major Contributor
Joined
Apr 24, 2016
Messages
3,075
Likes
2,180
Location
UK
Author, our resident expert DonH50

Jitter 101
Jitter is yet another one of those things not terribly hard to understand but with lots and lots of nuances and seemingly hidden details. To begin, let’s define some terms, starting with aperture time.

View attachment 8641

Figure 1 shows a signal we want to sample. It moves fastest (has the highest slew rate) at the center crossing. Zooming in, the time it takes the signal to change by 1 least-significant bit (lsb) in amplitude is the aperture time (tap). If we sample anywhere within this time window, the output will be the same code (assuming the amplitude starts and ends on a threshold). If we fall outside the window, the next code lower or higher will be output. For a sine wave of amplitude A and frequency f, the maximum slew rate is 2*pi*f*A (the magnitude of the first derivative with respect to time). For an N-bit ADC or DAC and that same sine wave input, the aperture time is 1/[(2^N)*pi*f] (the amplitude ratios out of the equation). Since it is the time required for the signal to pass through 1 lsb, the clock frequency (sampling rate) does not enter into the equation. Figure 2 shows the aperture time window for various frequencies and resolutions.

View attachment 8642

Time jitter is variation in the sampling time, which results in a corresponding change in sampled amplitude. Jitter that exceeds the aperture time causes the wrong codes to be output, reducing the ADC’s (or DAC’s) performance. The jitter can be random or deterministic (i.e. determined by some signal, be it the input, clock, power supply ripple, DSP, and/or some combination of those or other sources, including the radio transmitter down the road). Random normal (Gaussian) jitter with standard deviation equal to the aperture time causes about 8 dB reduction in SNR (a little over 1 bit of resolution loss).

Random jitter is just noise. It degrades (reduces) the SNR but does not add any nasty tones to the signal. It comes from three primary sources:

1. Thermal noise. Even just sitting there, the electronic particles in a resistor, wire, whatever are randomly moving around and bumping into each other. This creates noise, and the hotter it gets the farther and faster they move, creating even more noise. It is very broadband, extending (theoretically) into the THz (10^12) region. Real systems have filtering, intentional or not, that greatly limit the thermal noise bandwidth. This noise causes the sample time to vary a bit, and jitter is one result.

2. Ever look real closely at the water from a tap? It does not flow smoothly up close, even though from a couple of feet away it looks like a smooth stream. At any temperature above absolute zero, the electron flow that makes up current is not a steady stream, either. The electrons jump about randomly, in starts and stops, even though the overall trend is in one direction (at a given time). This is shot noise and happens whenever current flows. It is also very broadband.

3. The last noise source I’ll describe here is flicker noise, often called 1/f noise due to the 1/frequency characteristic it’s amplitude takes over much of it’s frequency range. (In fact, the slope can be 1/f^2, 1/f^3, etc. – and various combinations across the spectrum.) Flicker noise is caused by traps – places electrons (and holes) get “caught” and held by defects in materials (like wires, capacitors, resistors, etc.) The amount of time they get “held” varies and is random, but relatively long compared to other noise sources. This means it occurs primarily in the 1 to perhaps 10 Hz or so band for most audio components. (FETs are actually worse than bipolar transistors for flicker noise for various reasons a bit too esoteric to go into here.) While it can (and so it does) modulate the sampling circuits directly, it also causes phase modulation in the clock circuits (phase-locked loops, PLLs) used in data converter systems.

Deterministic jitter is much more insidious and I personally feel is the primary jitter component causing audible distortion. Deterministic means it is determined by some signal, and that is often not a signal we want in our system. These unwanted signals may not be related to the signal, and thus spurs from them really stand out to our ears. Even when related to the signal, deterministic jitter can reduce performance far more than random jitter by adding spurs that are much, much larger than simple random jitter (noise) adds. Examples will come later… First, a few causes:

1. Limited system bandwidth causes some deterministic jitter in all digital systems. In effect, limited bandwidth causes the sampling point to vary with the data (signal), adding signal-dependent deterministic jitter to our systems. Blah. I’ll come back to this one…

2. All real systems have a little bit of “memory” in them in the form of charge storage. This memory (hysteresis) can be stray (parasitic) capacitance or inductance, magnetic fields, etc. This tiny bit of memory means new signals coming in get corrupted a little bit by the previous signals, again introducing deterministic jitter into our systems.

3. Coupled signals are often the hardest to screen, identify, and fix. Any signal coupled into the clock creates deterministic jitter; that is, jitter determined by the coupled signal. Power supply ripple, the DSP clock in the AVR or CD/DVD/BRD player, the actual signal, external noise (radio/TV stations, cable amplifiers, the good buddy on his CB, etc.) can all sneak in through ground or power traces or even through the air to create deterministic jitter.

To get back to (1) briefly, look at Figure 3 below, which shows a few cycles in a digital bit stream. I have shown a […0,1,0,1,0,1,1,0,1…] pattern (sort of). Limited high-frequency bandwidth does not let the alternating 0/1 patterns reach full amplitude. If we look at the zero-crossing, where the data presumably changes, the slope is a little low (the red line is tilted a bit more) than the area where the signal has the 0,1,1 pattern and has time to reach full-scale. If we zoomed in very closely we’d see the crossing time is a little different for those two points due to the different slopes (which arise from the signal starting to transition from different levels).

View attachment 8643

Now, the top of the next (1,1) region is not flat; it slopes down a little bit. This indicates limited low-frequency bandwidth, i.e. it is not d.c.-coupled. For many reasons, wideband data systems are rarely d.c. coupled, and thus long strings of 1’s (or 0’s) can cause this to happen. The effect is again a slightly different crossing point because the signal starts from a different point, causing a different slope.

The last red line is on a part of the signal showing overshoot, where the signal actually shoots past the top and comes back down. Overshoot can improve the switching speed, but of course this means the edge is a little faster than the other edges, and again the center crossing is a little different. Aargh!

Before deciding all is lost, note that for digital signals these effects, while real, are rarely a problem in digital audio systems. The data rates are on the low end of what’s available, and error correction and careful signal construction (using tricks like dither to keep the signal always “busy”) results in extremely low bit error rates.

However, all these effects can affect the sampling clock, whether it is derived from the signal data stream (typical) or provided as a separate signal. Random and deterministic jitter on the ADC or DAC clock does cause real, measurable errors in the signals sent to our speakers. The audibility is often debated, of course; what a shock.

I am going to split the audio portion of this discussion into a separate thread. However, before leaving this one, I want to at least mention what it takes to do jitter measurement, if nothing else to explain why just asking somebody to measure it is often unfruitful. Audio jitter is fairly easy to measure because it is fairly large (10’s of ps to ns or more). Still, it takes some sophisticated equipment. At my workplace, measuring sub-ps (and into the fs) jitter requires clean low-jitter signal sources, pattern generators, digital sampling oscilloscopes (DSOs), and a host of filters, amplifiers, and specialized equipment that let us calibrate and compensate measurement error and extract (after much processing on a $2k computer running $10k to $100k of software) the true jitter numbers. We’re talking $100k signal sources, $250k bit error rate testers (BERTs), $150k and up DSOs, and $100k’s of extra amplifiers, cables, filters, and little black (gold, actually, often with heat sinks) boxes assembled into a complex test system. Perhaps $1M in equipment plus a few man-years of development. Your audio system is much lower frequency, of course, so maybe a mere $500k or so will get by…

Stay tuned for Part 2. - Don
All very good information of course. My criticism is that it is out of context i.e. it must be stressed that although jitter is present in horrendous quantities at various stages of the system, in any sensible setup (asynchronous USB DAC for example) only the jitter within the DAC/FIFO and its local clock matters. All the rest is completely eliminated through the system-level design. People do not understand this, which allows the myth to persist that cables contribute to "jitter". They dont - which is why digital streaming across the globe is indistinguishable from any other source of bits.
 

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
Rewrite the article and improve it. It was written years ago and undoubtedly could use updating, but I don't have the time right now. My life as a designer focused on data converters so my perspective is looking right at the DAC, not the interface or box including all the other components that is considered an audiophile DAC. I do not recall reinforcing that cables cause jitter, though in fact they do, but this article does not highlight the reclocking and isolation aspects incorporated in a typical component DAC (now meaning the box you buy, not the chip I design).
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,386
Location
Seattle Area
I like to caution members that such articles are written for free with no compensation of any sort. As such, I expect to see highest level of respect provided to our expert authors. If you have something to add, just add it but don't do it in the context of criticizing the author. Doing otherwise is the fastest ticket to not see anyone else volunteer to write them.
 

Shadrach

Addicted to Fun and Learning
Joined
Feb 24, 2019
Messages
662
Likes
947
Author, our resident expert DonH50

Jitter 101
Jitter is yet another one of those things not terribly hard to understand but with lots and lots of nuances and seemingly hidden details. To begin, let’s define some terms, starting with aperture time.

View attachment 8641

Figure 1 shows a signal we want to sample. It moves fastest (has the highest slew rate) at the center crossing. Zooming in, the time it takes the signal to change by 1 least-significant bit (lsb) in amplitude is the aperture time (tap). If we sample anywhere within this time window, the output will be the same code (assuming the amplitude starts and ends on a threshold). If we fall outside the window, the next code lower or higher will be output. For a sine wave of amplitude A and frequency f, the maximum slew rate is 2*pi*f*A (the magnitude of the first derivative with respect to time). For an N-bit ADC or DAC and that same sine wave input, the aperture time is 1/[(2^N)*pi*f] (the amplitude ratios out of the equation). Since it is the time required for the signal to pass through 1 lsb, the clock frequency (sampling rate) does not enter into the equation. Figure 2 shows the aperture time window for various frequencies and resolutions.

View attachment 8642

Time jitter is variation in the sampling time, which results in a corresponding change in sampled amplitude. Jitter that exceeds the aperture time causes the wrong codes to be output, reducing the ADC’s (or DAC’s) performance. The jitter can be random or deterministic (i.e. determined by some signal, be it the input, clock, power supply ripple, DSP, and/or some combination of those or other sources, including the radio transmitter down the road). Random normal (Gaussian) jitter with standard deviation equal to the aperture time causes about 8 dB reduction in SNR (a little over 1 bit of resolution loss).

Random jitter is just noise. It degrades (reduces) the SNR but does not add any nasty tones to the signal. It comes from three primary sources:

1. Thermal noise. Even just sitting there, the electronic particles in a resistor, wire, whatever are randomly moving around and bumping into each other. This creates noise, and the hotter it gets the farther and faster they move, creating even more noise. It is very broadband, extending (theoretically) into the THz (10^12) region. Real systems have filtering, intentional or not, that greatly limit the thermal noise bandwidth. This noise causes the sample time to vary a bit, and jitter is one result.

2. Ever look real closely at the water from a tap? It does not flow smoothly up close, even though from a couple of feet away it looks like a smooth stream. At any temperature above absolute zero, the electron flow that makes up current is not a steady stream, either. The electrons jump about randomly, in starts and stops, even though the overall trend is in one direction (at a given time). This is shot noise and happens whenever current flows. It is also very broadband.

3. The last noise source I’ll describe here is flicker noise, often called 1/f noise due to the 1/frequency characteristic it’s amplitude takes over much of it’s frequency range. (In fact, the slope can be 1/f^2, 1/f^3, etc. – and various combinations across the spectrum.) Flicker noise is caused by traps – places electrons (and holes) get “caught” and held by defects in materials (like wires, capacitors, resistors, etc.) The amount of time they get “held” varies and is random, but relatively long compared to other noise sources. This means it occurs primarily in the 1 to perhaps 10 Hz or so band for most audio components. (FETs are actually worse than bipolar transistors for flicker noise for various reasons a bit too esoteric to go into here.) While it can (and so it does) modulate the sampling circuits directly, it also causes phase modulation in the clock circuits (phase-locked loops, PLLs) used in data converter systems.

Deterministic jitter is much more insidious and I personally feel is the primary jitter component causing audible distortion. Deterministic means it is determined by some signal, and that is often not a signal we want in our system. These unwanted signals may not be related to the signal, and thus spurs from them really stand out to our ears. Even when related to the signal, deterministic jitter can reduce performance far more than random jitter by adding spurs that are much, much larger than simple random jitter (noise) adds. Examples will come later… First, a few causes:

1. Limited system bandwidth causes some deterministic jitter in all digital systems. In effect, limited bandwidth causes the sampling point to vary with the data (signal), adding signal-dependent deterministic jitter to our systems. Blah. I’ll come back to this one…

2. All real systems have a little bit of “memory” in them in the form of charge storage. This memory (hysteresis) can be stray (parasitic) capacitance or inductance, magnetic fields, etc. This tiny bit of memory means new signals coming in get corrupted a little bit by the previous signals, again introducing deterministic jitter into our systems.

3. Coupled signals are often the hardest to screen, identify, and fix. Any signal coupled into the clock creates deterministic jitter; that is, jitter determined by the coupled signal. Power supply ripple, the DSP clock in the AVR or CD/DVD/BRD player, the actual signal, external noise (radio/TV stations, cable amplifiers, the good buddy on his CB, etc.) can all sneak in through ground or power traces or even through the air to create deterministic jitter.

To get back to (1) briefly, look at Figure 3 below, which shows a few cycles in a digital bit stream. I have shown a […0,1,0,1,0,1,1,0,1…] pattern (sort of). Limited high-frequency bandwidth does not let the alternating 0/1 patterns reach full amplitude. If we look at the zero-crossing, where the data presumably changes, the slope is a little low (the red line is tilted a bit more) than the area where the signal has the 0,1,1 pattern and has time to reach full-scale. If we zoomed in very closely we’d see the crossing time is a little different for those two points due to the different slopes (which arise from the signal starting to transition from different levels).

View attachment 8643

Now, the top of the next (1,1) region is not flat; it slopes down a little bit. This indicates limited low-frequency bandwidth, i.e. it is not d.c.-coupled. For many reasons, wideband data systems are rarely d.c. coupled, and thus long strings of 1’s (or 0’s) can cause this to happen. The effect is again a slightly different crossing point because the signal starts from a different point, causing a different slope.

The last red line is on a part of the signal showing overshoot, where the signal actually shoots past the top and comes back down. Overshoot can improve the switching speed, but of course this means the edge is a little faster than the other edges, and again the center crossing is a little different. Aargh!

Before deciding all is lost, note that for digital signals these effects, while real, are rarely a problem in digital audio systems. The data rates are on the low end of what’s available, and error correction and careful signal construction (using tricks like dither to keep the signal always “busy”) results in extremely low bit error rates.

However, all these effects can affect the sampling clock, whether it is derived from the signal data stream (typical) or provided as a separate signal. Random and deterministic jitter on the ADC or DAC clock does cause real, measurable errors in the signals sent to our speakers. The audibility is often debated, of course; what a shock.

I am going to split the audio portion of this discussion into a separate thread. However, before leaving this one, I want to at least mention what it takes to do jitter measurement, if nothing else to explain why just asking somebody to measure it is often unfruitful. Audio jitter is fairly easy to measure because it is fairly large (10’s of ps to ns or more). Still, it takes some sophisticated equipment. At my workplace, measuring sub-ps (and into the fs) jitter requires clean low-jitter signal sources, pattern generators, digital sampling oscilloscopes (DSOs), and a host of filters, amplifiers, and specialized equipment that let us calibrate and compensate measurement error and extract (after much processing on a $2k computer running $10k to $100k of software) the true jitter numbers. We’re talking $100k signal sources, $250k bit error rate testers (BERTs), $150k and up DSOs, and $100k’s of extra amplifiers, cables, filters, and little black (gold, actually, often with heat sinks) boxes assembled into a complex test system. Perhaps $1M in equipment plus a few man-years of development. Your audio system is much lower frequency, of course, so maybe a mere $500k or so will get by…

Stay tuned for Part 2. - Don
Thanks.:) I'm going to get some of my old physics books out now.
 

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
You're welcome. Do read Cosmik's criticism and my response as well as pay close attention to the context statements in the original article. This applies right at the data converter (ADC or DAC) and does not assume any reclocking or other jitter suppression techniques widely used today. At the time I wrote the article (August 2010) asynchronous DACs were very new and few; now, most every DAC provides very good to excellent jitter suppression.

In my day job, cables are a significant source of inter-symbol interference (ISI) that causes data (signal)-dependent jitter. At multi-GHz frequencies and with stringent impedance matching constraints they are much more important than at audio. And the data converters I designed were largely multi-GS/s devices so again but underlying basis is much different than audio. That said, the basics and underlying theory are valid.

IMO! - Don

p.s. This was the first of four articles on jitter.
 
Last edited:

Vijay_kumar74

Member
Forum Donor
Joined
Sep 2, 2021
Messages
33
Likes
3
Location
Delhi, India
Stay tuned for Part 2. - Don
Did it ever get published? If yes, could someone please paste the link?

it must be stressed that although jitter is present in horrendous quantities at various stages of the system, in any sensible setup (asynchronous USB DAC for example) only the jitter within the DAC/FIFO and its local clock matters. All the rest is completely eliminated through the system-level design. People do not understand this, which allows the myth to persist that cables contribute to "jitter". They dont - which is why digital streaming across the globe is indistinguishable from any other source of bits.
I fail to understand how jitter gets introduced as part of digital data transmission? Through USB transfer or by non-audiophile switches. Can't these be handled using data transfer protocols.. using bit parity checking or other means to ensure bit perfect digital data transfer? I can understand Jitter introduced while D->A conversion taking place but jitter at the time of digital data transfer/by cables/switches? Am unable to understand.
 

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
Did it ever get published? If yes, could someone please paste the link?
See the table of contents post for other articles linked in my signature.

I fail to understand how jitter gets introduced as part of digital data transmission? Through USB transfer or by non-audiophile switches. Can't these be handled using data transfer protocols.. using bit parity checking or other means to ensure bit perfect digital data transfer? I can understand Jitter introduced while D->A conversion taking place but jitter at the time of digital data transfer/by cables/switches? Am unable to understand.
Jitter is present in any digital signal transmission (USB, Ethernet, WiFI, PCIe, SATA, SAS, etc. etc. etc.) as noise "on the wire". There are many sources of jitter that impact digital transmission, but at audio rates it is basicaly a non-issue unless something is broken. Cables limit bandwidth and add ISI (intersymbol interference) and other effects. But, modern audio DACs recover the data and then reclock it so jitter on the incoming datastream is rejected (isolated) from the audio output. At the time this article was originally written, asynchronous DACs were rare and so noise on the input stream could appear on the audio output. That is no longer the case for the vast majority (probably "all") audio DACs you can buy today.
 

Vijay_kumar74

Member
Forum Donor
Joined
Sep 2, 2021
Messages
33
Likes
3
Location
Delhi, India
See the table of contents post for other articles linked in my signature.


Jitter is present in any digital signal transmission (USB, Ethernet, WiFI, PCIe, SATA, SAS, etc. etc. etc.) as noise "on the wire". There are many sources of jitter that impact digital transmission, but at audio rates it is basicaly a non-issue unless something is broken. Cables limit bandwidth and add ISI (intersymbol interference) and other effects. But, modern audio DACs recover the data and then reclock it so jitter on the incoming datastream is rejected (isolated) from the audio output. At the time this article was originally written, asynchronous DACs were rare and so noise on the input stream could appear on the audio output. That is no longer the case for the vast majority (probably "all") audio DACs you can buy today.
Yes. What I meant was how jitter being an issue in digital data transfer even if being introduced as part of thermal noise, flicker noise or other normal conditions. I was more like thinking out loud about usefulness of DDCs/audiophile switches to handle digital data transport jitter. I know ASR's stand/conclusion on these. :)
 

DonH56

Master Contributor
Technical Expert
Forum Donor
Joined
Mar 15, 2016
Messages
7,835
Likes
16,497
Location
Monument, CO
Yes. What I meant was how jitter being an issue in digital data transfer even if being introduced as part of thermal noise, flicker noise or other normal conditions. I was more like thinking out loud about usefulness of DDCs/audiophile switches to handle digital data transport jitter. I know ASR's stand/conclusion on these. :)
I am not sure I understand your question. Last I checked, I think the standard we use in my day job listed something like 27 different jitter sources. But modern receivers do an outstanding job of recovering the data, and modern DACs buffer and reclock the data, so unless you get bit errors (which will cause dropouts and stuttering sounds) jitter just is not a problem. There is absolutely no way jitter on the incoming data stream can change the sound, make it warmer or deeper or whatever, because the DAC gets the bits and generates an output using its own, isolated, clock source.

"Audiophile" switches and such just cannot do what some people claim; the data stream just does not work that way. For example, Ethernet transmits bits orders of magnitude faster than your DAC can output them, and Ethernet sends the data in groups of bits called packets. Part of your DAC must get those packets, process them to get the raw data bits for your audio signal from the rest of the error correction and header information encoded with them, then combine the packets in the right order and buffer them to provide a constant data stream at the proper rate for the DAC itself inside the box. The DAC has its own clock source to prevent incoming jitter from affecting the output. And of course there are lots of switches, routers, computers, and wires getting that data from the source to your DAC in the first place, all of which can add noise and jitter. The Internet would not work, WiFi would not work, your computer would not work, the disc drives inside would not work, and so forth and so on if data integrity was as big a problem as some companies would have you believe.

Ethernet is a differential signal through shielded wires and galvanically isolated per spec so should not couple noise to your DAC. A bad receiver or cable could couple noise, but that would likely get through to the audio directly and not in the data stream (bits). Any spec-compliant Ethernet switch or router should not have that problem, whether it is $20 or $3000.

@amirm has tested and proven audiophile Ethernet switches offer no audible benefit whatsoever. Those who believe they do will continue to do so, and manufacturers will continue to make money feeding their ignorance and gullibility. ASR is here to help... :)
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,386
Location
Seattle Area
What I meant was how jitter being an issue in digital data transfer even if being introduced as part of thermal noise, flicker noise or other normal conditions.
Adding on to Don's explanation, "data at rest," i.e. stored on a computer has no jitter. The moment you transmit it anywhere, noise and as a result, jitter will be introduced. In digital systems, that noise is filtered out until it can't at which point data is lost. Once filtered, the data can be used without jitter.

Note that vast majority of "jitter" that I measure in DACs is internally generated in the DAC. Various sources of noise and interference pollute the operation of the DAC chip which then shows up as elevated noise floor and spurious tones.
 

Vijay_kumar74

Member
Forum Donor
Joined
Sep 2, 2021
Messages
33
Likes
3
Location
Delhi, India
Thanks for detailed explanation. I was also questioning usefulness of DDCs/Audiophile network switches in improving audio quality by reducing jitter, as claimed by some audiophiles in some other channels/forums. Or other way, trying to find logical reason behind their claims. Logically, I am unable to find the reason .. but can't ignore or deny empirical evidences also .. for now.
Though I must admit, I find lot of logical gaps in subjective audiophile world. Biggest one being lack of supporting data or proofs. Many times lack of exact reproducible steps to cross validate the claims. Basically lack of discipline (engineering/scientific like) seems a big issue in subjective world. Hope the gap gets reduced between both worlds.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
44,368
Likes
234,386
Location
Seattle Area
The network clock is not used for anything to do with playback of audio. It runs at entirely different speed that is not possibly useful for audio. That clock determines the speed with which the network interface gathers data. That gathered data is put in memory and then played at the audio rate as controlled by the media player or the DAC. For this reason, any talk of network jitter and audio jitter is just plain wrong. It is hard to find people who understand this domain end to end so you get people saying wrong things.
 

MaxwellsEq

Major Contributor
Joined
Aug 18, 2020
Messages
1,628
Likes
2,426
It is hard to find people who understand this domain end to end so you get people saying wrong
I've worked in analogue and digital audio. I've also worked in large Ethernet and IP installations.

In an Ethernet, there is no "master clock". All of the devices have their own clock, but they are not synchronised. When a device is plugged in to a switch, it negotiates the highest rate and Simplex Vs Duplex. It an then assume all packets will arrive at the negotiated rate. It then depends on its internal clock to extract the bits, which it writes into its buffer until all the packet has arrived. Because the packets are relatively short, clock variations don't matter too much.

For modern studio engineering (e.g. ST2110) a master clock is required as part of the specification over the network and it uses PTP.
 

wgh52

Member
Joined
Feb 25, 2021
Messages
62
Likes
25
Location
Germany
Hello digital Audio experts.

I'm not sure if my question fits here completely, but I'd like a clarification regarding SPDIF signals.

Correct me if I'm wrong, but as far as I understand SPDIF signals carry the bit values and the clock (bit rate) signal coded into the transition to transition time and not in the signal level being high or low. If that is the case, there would be some relevance in an SPDIF Signal jittering more or less - no? (Although, SPDIF has not been mentioned here at all, which makes me wonder as well)

On the subjective side my experience was several years ago, that a DEQX PDC sound was sensitive to incoming SPDIF signal quality. Using a Mutec MC-3+ Toslink/SPDIF/AES3 Reclocker/Masterclock resolved this sensitivity to the subjectively positive.

So, how do my observations and current understanding fit with the acticles descriptions above?

Thanks for helping me understand better.
Winfried
 

Keith_W

Major Contributor
Joined
Jun 26, 2016
Messages
2,523
Likes
5,798
Location
Melbourne, Australia
Guten Tag, Winfried.

I came across a great analogy for SPDIF vs. USB transmission in a Youtube video. Imagine that you have a musician playing the piano, and you are in charge of telling him what notes to play. You can give him a whole sheet of music, and the musician can play until he reads the whole page, then you place another sheet in front of him. This is called "asynchronous transmission", and this is how USB works. Or, you could give him music one note at a time, in which case the timing of the notes depends on YOU to give him the notes at the proper time. This is called "synchronous transmission", which is how SPDIF works.

This means that synchronous connections are more prone to jitter / have the potential for more jitter if it weren't for mitigating technology like Phase Lock Loops. Basically, the receiving device adjusts the frequency of its own clock until it matches the incoming signal and pushes jitter down to inaudible levels.
 
Top Bottom