Why is jitter a problem in audio?
I mean, I know what jitter is, and why it is important. In the industry where I work, we measure jitter in picoseconds. That's why I can't understand why jitter large enough to be perceived in an audio signal is not trivially easy to solve.
In the digital systems I am used to, signals pass through a long pipeline, being reclocked every step of the way. Jitter only matters if it is large enough that the signal is not valid when the clock happens. Does the data from the CD (or whatever your digital source is) really not get reclocked all the way from the laser to the DAC? If so, why not?
Digital signals are passed around serially. The actual digital signal (from a CD) is 32 bits per sample. 32 x 44.1KHz is 1,411,200 bits per second. That means that each bit only has a .709 uS window to bounce around in (any larger and bits are going to be misread entirely). Is jitter on that order of magnitude audible?
So what am I missing here? Why do people spend thousands of dollars on a CD transport?
I mean, I know what jitter is, and why it is important. In the industry where I work, we measure jitter in picoseconds. That's why I can't understand why jitter large enough to be perceived in an audio signal is not trivially easy to solve.
In the digital systems I am used to, signals pass through a long pipeline, being reclocked every step of the way. Jitter only matters if it is large enough that the signal is not valid when the clock happens. Does the data from the CD (or whatever your digital source is) really not get reclocked all the way from the laser to the DAC? If so, why not?
Digital signals are passed around serially. The actual digital signal (from a CD) is 32 bits per sample. 32 x 44.1KHz is 1,411,200 bits per second. That means that each bit only has a .709 uS window to bounce around in (any larger and bits are going to be misread entirely). Is jitter on that order of magnitude audible?
So what am I missing here? Why do people spend thousands of dollars on a CD transport?
preiter said:
Good point. In another thread here, several people did all kinds of tests with CD transports, from very expensive to 15 $ cheap PC drives. In each case copying from any drive to any other, repeatedly, even to itself, always got an exact bit-for-bit copy. They tested bit-for-bit.
So, if you reclock your data at the DAC, whatever is before it, including the drive, doesn't bother at all. Assuming, of course, that the drive is accurate enough in frequency to keep the DAC filled. That appears to be the case.
The rest is all anecdotal.
Jan Didden
Jitter is important because it can be audible. CD playback systems are real-time, so the clock jitter directly affects the D/A converter output. Read this article for more:
http://www.positive-feedback.com/Issue22/nugent.htm
Steve N.
Empirical Audio
Manufacturer
http://www.positive-feedback.com/Issue22/nugent.htm
Steve N.
Empirical Audio
Manufacturer
Re: Re: Re: Re: Why do we care about jitter?
What are you taking about? There are no clocks inside 90% of commercially available DAC's, except some with asynch. upsampling clocks, which dont qualify. The few with native reclocking circuits are far from perfect. In other words, they do not eliminate the effects of jitter on the input of the DAC. I have experience with many of these because I have modded them.
Steve N.
Empirical Audio
Manufacturer/modder
janneman said:
What are you taking about? There are no clocks inside 90% of commercially available DAC's, except some with asynch. upsampling clocks, which dont qualify. The few with native reclocking circuits are far from perfect. In other words, they do not eliminate the effects of jitter on the input of the DAC. I have experience with many of these because I have modded them.
Steve N.
Empirical Audio
Manufacturer/modder
I perused the data sheet for the CSS8414 and it reclocks the incoming data with a PLL. It seems to me that should do a pretty good job of reducing the jitter.
Exactly what amount of jitter do people claim is audible? I just have trouble understanding why this is a problem that would cost more than $20 to fix.
Also, I have seen some systems that reclock the signal at a much higher rate? Why would you do that? Aren't you just reclocking the jitter-skewed signal in the wrong place?
Exactly what amount of jitter do people claim is audible? I just have trouble understanding why this is a problem that would cost more than $20 to fix.
Also, I have seen some systems that reclock the signal at a much higher rate? Why would you do that? Aren't you just reclocking the jitter-skewed signal in the wrong place?
Supposedly, jitter is audible in the picosecond range. That is why I pointed it out in my previous post. Whether it is audible or not is subject for lengthy debate (and I'm sure has been done here many times), but regardless, many folks try to reduce jitter to tens or picoseconds or less. Also, it is not true that reclocking eliminates jitter completely. That has been discussed many times as well.
Preiter,
The general consensus seems to be that jitter of the order of <100ps is audible. I personally haven't read any documentation detailing controlled listening tests that show this to be true, but of course that doesn't mean that it isn't. I think that when you get down to jitter of this level you need pretty special PLLs to make it happen. The CS8416 IIRC gives a clock with around 200ps jitter (I could be wrong). Apparently this is not good enough, especially if the jitter spectrum is mostly in the audible range.
Apparently.
The general consensus seems to be that jitter of the order of <100ps is audible. I personally haven't read any documentation detailing controlled listening tests that show this to be true, but of course that doesn't mean that it isn't. I think that when you get down to jitter of this level you need pretty special PLLs to make it happen. The CS8416 IIRC gives a clock with around 200ps jitter (I could be wrong). Apparently this is not good enough, especially if the jitter spectrum is mostly in the audible range.
Apparently.
preiter said:
Hi
When it comes to retrieving data, CD systems are easy compared to other telecom systems. The jitter realy is important at the D toA conversion, as time errors are then converted to amplitude errors.
In my perception research, jiter in the ps range is audible.
Transports differ in sound due to the jitter they put out at the SPDIF interface. DACs retrieve the clock based on the SPDIF signal, industrial input receivers like 8412/14 have a PLL bandwidth of 20kHz which is way too much to reduce jitter to sensible values.
I hope this explains a bit
best
Guido
Wingfeather said:
Assuming the highest audible frequency is 20KHz or 50uS wavelength. Moving those signals around in the time domain by 100pS would be moving them by .005%. Or, thought of another way, it would be equivalent to disturbing them with a 10GHz signal.
I'm not sure if that's a totally valid analysis, but it does give an idea of the magnitude of the numbers that we are talking about. It just doesn't seem plausible to me that it would be audible.
Re: Re: Re: Re: Re: Why do we care about jitter?
My point was that the last clocking, say at the DAC, is determining the final jitter performance and that whatever happens before that is irrelevant (for jitter). And I agree that no clocking is perfect. So, even if you succeed to get a perfectly jitter-free signal from your transport into the DAC, it's still the DAC that determines final performance. So, you might as well get the cheapest transport you can get and spend some more money on the final clocking.
Jan Didden
audioengr said:
My point was that the last clocking, say at the DAC, is determining the final jitter performance and that whatever happens before that is irrelevant (for jitter). And I agree that no clocking is perfect. So, even if you succeed to get a perfectly jitter-free signal from your transport into the DAC, it's still the DAC that determines final performance. So, you might as well get the cheapest transport you can get and spend some more money on the final clocking.
Jan Didden
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.