Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: (Not a) good explanation of jitter in TAS (Read 88971 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

(Not a) good explanation of jitter in TAS

Reply #75 –
Quote from: rpp3po on
Very interesting comments.

The problem I generally see with externally generated jitter, either through up-/downsampling or electronically, is the applicability of those results. You can take it so far, that you can hear at least something, i. e. what jitter of model m at gain g does or does not sound like. After that you will have several pairs m, g that seem to be relevant. But those then have to be translated and tested against real world implementations.


There is quite a bit of extant testing of real-world equipment that shows what kind of signals produced the jittering. IOW, the spectra of common jitter signals are either known or knowable.  It makes sense to test with jitter signals that resemble real-world jitter signals.


Quote
Wouldn't it make more sense to route test signals into a common DAC known to be sensible against jitter, one from a low end onboard S/PDIF source and another of very high quality, make more sense? That's about the worst it can get in real life. If that already wasn't audible, testing could end. If it was, other common DACs could be fed with the same signal.


The most sensible thing might be to take advantage of the tests and sensitivity data that is already are the scientific/professional literature. The bottom line is that there's no excuse for a modern audio component to have audible jitter.

(Not a) good explanation of jitter in TAS

Reply #76 –
Would it be too much to ask for a thread split? The original thread pales in discussion to the substantially cooler discussion that is taking place right now.

(Not a) good explanation of jitter in TAS

Reply #77 –
Quote from: Arnold B. Krueger on
Actually, its pretty easy to add jitter to a SP/DIF signal. I've done it with maybe $10 worth of parts on a protoboard plus an analog signal source for the signal that is to be the jitter.

Take a SP/DIF signal and use a high speed comparator or schmidt trigger chip to turn it into a square wave (Real world sp/dif signals are often band-limited and look a lot more like a sine wave than a square wave).  Feed that through a low pass filter to create a wave with a significant rise time. Then mix in variable amounts of the analog jitter signal. Finally, use another comparator or schmidt trigger input gate to create the signal with jitter. The analog signal will slide the trigger point of the digital signal back and forth along its rise time slope, and this will change the timiing of the SP/DIF signal.  The first comparator to square the input signal is optional, particularly if the SP/DIF signal coming in is very robust.


Strictly speaking, that is a simulation of only a very specific kind of jitter (data dependent/cable dependent jitter), and does not really answer the general problem.

(Not a) good explanation of jitter in TAS

Reply #78 –
Quote from: EliasGwinn on
An FFT may not be able to determine audibility, but it can determine susceptibility.  If we put a DAC on an AP machine and increase jitter, the FFT will show whether the DAC is immune to the change.  Most are not.


Quote from: EliasGwinn on
And, arguably, low-freq is the most detrimental jitter because it modulates the fundamentals to frequencies near-by (+/- the jitter frequency), which can cause things to sound out-of-tune (like one of a trio of piano strings is out of tune).


To some (admittedly slight) degree, aren't these statements inconsistent? A FFT is enough to establish masking thresholds for a steady state signal, and a STFT can probably get you most of the way there with real music, right?

If we really are going to break this down to instantaneous frequencies, I think the effect is going to be extremely difficult to reconcile with masking issues. 30ns amplitude jitter with a 500hz jitter signal yields a sideband amplitude of.... -210db? I mean, I'm aware Benjamin/Gannon actually did find thresholds in this vicinity, but the sheer magnitudes involved make me really suspicious about claims at any lower levels.

(Not a) good explanation of jitter in TAS

Reply #79 –
Quote from: Axon on
Would it be too much to ask for a thread split? The original thread pales in discussion to the substantially cooler discussion that is taking place right now.

All the more reason to keep it right here, IMO.  It's one thing to condemn an article as being nothing more than irrelevant fluff and question the motivations behind its creation; another still to give people further insight into why it's irrelevant fluff.  I'm happy to see that this thread can actually be useful.

EDIT: Now if another mod or admin deems the split appropriate, that's cool with me too.  I can definitely see splitting as useful if it improves the chances of getting good information from a title-based search.

(Not a) good explanation of jitter in TAS

Reply #80 –
Quote from: Axon on
Quote from: Arnold B. Krueger on
Actually, its pretty easy to add jitter to a SP/DIF signal. I've done it with maybe $10 worth of parts on a protoboard plus an analog signal source for the signal that is to be the jitter.

Take a SP/DIF signal and use a high speed comparator or schmidt trigger chip to turn it into a square wave (Real world sp/dif signals are often band-limited and look a lot more like a sine wave than a square wave).  Feed that through a low pass filter to create a wave with a significant rise time. Then mix in variable amounts of the analog jitter signal. Finally, use another comparator or schmidt trigger input gate to create the signal with jitter. The analog signal will slide the trigger point of the digital signal back and forth along its rise time slope, and this will change the timiing of the SP/DIF signal.  The first comparator to square the input signal is optional, particularly if the SP/DIF signal coming in is very robust.


Strictly speaking, that is a simulation of only a very specific kind of jitter (data dependent/cable dependent jitter), and does not really answer the general problem.


I really don't think so.  With the  procedures I have described, you have a free choice of the signal to use to add jitter.

Data-dependent jitter would involve using the data being transmitted to add jitter. I call that "self jitter". While that is possible with the technique I used, it isn't what I actually did.

In the experiments I did either hardware or software, I used an independent tone generator to add jitter to a variety of seperately generated tones and musical signals.  I chose this means because it more closely represents the most common forms of jitter that I have seen in actual equipment.

Note that if you try to repeat my hardware approaches to adding jitter in controlled kinds and amounts, it might not seem to be working at all with most modern DACs. They will buffer the signal and make the jitter go away!

(Not a) good explanation of jitter in TAS

Reply #81 –
Quote from: EliasGwinn on
Different types of jitter DO sound different.


Agreed, and with a bullet!  Low frequency jitter sounds like vibratro.

Those of us who were forced to listen to vinyl in the days when it ruled had to spend years listening to music with a number of different sources of audible, low frequency jitter. 

The literature of audiblity (e.g. Zwicker and Fastl) describes FM distortion as "roughness". 

I would describe the jitter due to an off-center punched LP as having cyclic roughness. The FM distortion due to warps is roughness with a faster cycle. FM distortion due to the interaction of offset arms and bass signals is a different kind of roughness. 

Quote
More importantly, different converters are susceptible to jitter at different frequencies.


Agreed, and that includes jitter in their own clocks.

Quote
Specifically, most are NOT immune at low frequencies (<1 kHz).


That would be IME untrue. The most common kind of converter that consumers listen to are in surround decoders. Surround decoders must have relatively large buffers, and they also seem to have clock regeneration circuits that are effective at producing a stable clock regardless of the kind of jitter. That is what my experiments showed. I used jitter frequencies down into the 20 Hz range.


Quote
Well-designed PLL's can settle high-frequency jitter, but doesn't do anything to low-frequency jitter.


A PLL can be designed to address low frequency jitter. I know that DAC chip clock jitter circuits generally address only high frequency jitter, but I believe that is because they are more likely to encounter that problem, even in systems where the clock was stabilzed well in previous circuits.

Quote
And, arguably, low-freq is the most detrimental jitter because it modulates the fundamentals to frequencies near-by (+/- the jitter frequency), which can cause things to sound out-of-tune (like one of a trio of piano strings is out of tune).


The actual perception of music being out-of-tune involves very low jitter frequencies, generally subsonic frequencies. At audible jitter frequencies, it sounds like roughness or vibrato. At high frequencies, the vibrato effect is less but the sense of roughness remains.  The most common jitter frequencies that are observed in real world equipment are IME related to the power line.

One of the ironies of high end audio illogic is that after the high end ragazines went on a tear wailing incessantly about digital jitter for years, some impressionable audiophiles returned to listening to vinyl to avoid having their enjoyment of music harmed by digital jitter. Of course, vinyl generally has orders of magnitudes more jitter than good digital, and most of it is at low frequencies where it is really audible and nasty.


In short, what the high end audio ragazines did starting in the 80s was to train people to be hysterical about parts-per-million poison, and then directed them to start a daily regimen of parts-per-thousand of the same or worse poison.

(Not a) good explanation of jitter in TAS

Reply #82 –
Quote from: Arnold B. Krueger on
Note that if you try to repeat my hardware approaches to adding jitter in controlled kinds and amounts, it might not seem to be working at all with most modern DACs. They will buffer the signal and make the jitter go away!


Are you sure about re-clocking (considerable buffering without some form of re-clocking doesn't make sense)? S/PDIF does not transmit a bit rate field, so the receiving clock would have to continuously monitor the incoming rate and adjust to its mid term average or run out of sync. Do you know any DACs with considerable amounts of latency? That would also be a side effect of buffering. All DACs I know are pretty close to realtime, thus cannot be building up long queues internally.

Apart from better PLL implementations I don't think that re-clocking is the standard for modern DACs. Or do you have some reference?

ASRC re-clocks the input to a target sample rate and works very well. But that's a feature generally only available on discrete chips, not integrated into common DACs.

(Not a) good explanation of jitter in TAS

Reply #83 –
Quote from: rpp3po on
Apart from better PLL implementations I don't think that re-clocking is the standard for modern DACs. Or do you have some reference?

ASRC re-clocks the input to a target sample rate and works very well. But that's a feature generally only available on discrete chips, not integrated into common DACs.


Exactly.  Some modern converters (even 'hi-end') don't even employ a local crystal, simply using the clock from the AES receiver.

Atb,
-e

(Not a) good explanation of jitter in TAS

Reply #84 –
Quote from: rpp3po on
Quote from: Arnold B. Krueger on
Note that if you try to repeat my hardware approaches to adding jitter in controlled kinds and amounts, it might not seem to be working at all with most modern DACs. They will buffer the signal and make the jitter go away!


Are you sure about re-clocking (considerable buffering without some form of re-clocking doesn't make sense)?


Re-clocking and buffering go hand-and-hand.

If you are going to change the timing of clock pulses, the corresponding data has to held someplace until its clock pulse comes up for output.

Quote
S/PDIF does not transmit a bit rate field, so the receiving clock would have to continuously monitor the incoming rate and adjust to its mid term average or run out of sync.


That is in fact what usually happens. Unless you resample the data, the final conversion clock pulses have to have the same average frequency as the origional data. This is usually the case.

In SP/DIF the clock pulses for final conversion to analog are obtained from the input data. If the input data is jittered (distorted in the time domain) by one means or another, the analog data that is output will have jitter unless you purify the clock. The usual approach is to put the data into a buffer and filter the dervied clock pulses in the time domain, usually using a PLL.  The purified clock is used to run the DAC.

My old DA500 probably did not do a lot to purify the clock it derived from its SP/DIF input.  A surround decoder is DSP-driven. Pure stereo operation is actually a degenerate compatibility mode that is obtained by bypassing a most of the usual decoding process. To decode a perceptually coded signal, there is a necessary implication of buffering and expansion of the data. The buffering of the data for stereo is done by default.

Quote
Do you know any DACs with considerable amounts of latency?


I've actually never checked the latency of a surround decoder, but I'm sure that there is lots of it.

Quote
That would also be a side effect of buffering.


That I agree with, and for audio production purposes, latency is usually minimized. However right now, I'm not talking about audio production, I'm  talking about consumers listening to music and watching video.

Quote
All DACs I know are pretty close to realtime, thus cannot be building up long queues internally.


You're talking about DACs that are being used for audio production. You're also thinking about just the hardware DAC, not the process of playing music.

How much latency is there in playing music with say, Foobar? Well the answer is always huge because there are always seconds, minutes,  hours, days and even years between producing music for distribution, and people actually listening to it. When you're playing music on a PC, the buffering process started when the music file was created. There's additional buffering in the music player.

Quote
Apart from better PLL implementations I don't think that re-clocking is the standard for modern DACs. Or do you have some reference?


I'm speaking about DACs in the sense of people listening to music on a PC or with a dedicated digital player.


Quote
ASRC re-clocks the input to a target sample rate and works very well. But that's a feature generally only available on discrete chips, not integrated into common DACs.


If you look back in my recent posts, you'll see a disclaimer - I said that in this day and age, most people who listen to music through DACs do so in the context of something like a surround receiver. That was too narrow - the list of devices needs to be expanded to PCs and dedicated digital players.  The buffering that reduces or eliminates jitter is generally not in a single-purpose DAC chip, but in the music player taken as a whole.

The initial problems with CD jitter came about when audio's high end foolishly split the CD player up into a transport and a stand-alone DAC.  The first generation CD players like the CDP 101 had no audible problems with jitter - I've measured several of them. CD players by definition buffer and reclock the audio data.

Splitting the CD player up into 2 chassis introduced many problems that were not initially addressed. This is a case where the high end created a problem where none existed, ranted and raved about it for over 20 years, and then ignored the fact that the basic problems caused by putting the DAC and the transport into 2 boxes was cured by surround processors and receivers about 8 years ago.

Even in computer audio production, there is *some* buffering. Many device drivers and/or DAW programs have adjustments for latency. There always has to be some buffering that is involved with latency. However, 1 millisecond of latency inplies storing 44 samples, and that is more than enough to handle a wide range of problems caused by data that is jittered. 

If you think about the actual processing of grabbing data off a disk and sending it out to a DAC, there is massive amounts of jitter (stop-and-go flow of data) that is implied by getting blocks of data data and putting it into output buffers. As long as the buffer has data in it  and it is converted to analog with a steady clock, there's no reason why the data flow shouldn't be as smooth as is desired, and the jitter will be vanishing.
 

(Not a) good explanation of jitter in TAS

Reply #85 –
Quote from: EliasGwinn on
Quote from: rpp3po on
Apart from better PLL implementations I don't think that re-clocking is the standard for modern DACs. Or do you have some reference?

ASRC re-clocks the input to a target sample rate and works very well. But that's a feature generally only available on discrete chips, not integrated into common DACs.


Exactly.  Some modern converters (even 'hi-end') don't even employ a local crystal, simply using the clock from the AES receiver.


There's no reason for a standard DAC to have a crystal. The device sending the digital data either provides a separate but parallel clock signal, or the clock is derived from the input digital data stream. The latter is far and away the most common situation.

If you see a crystal in a DAC, either the DAC resamples asynchronously, or the crystal is actually there for the benefit of the ADC that is in the same box.  Most so-called DACs that are used in audio production also have an ADC in the same box.

Asynchronous resampling has to violate the principle of bit-perfect data transmission.

(Not a) good explanation of jitter in TAS

Reply #86 –
Great post!  Thanks for the overview.

(Not a) good explanation of jitter in TAS

Reply #87 –
Arnold - when you say that "Re-clocking and buffering go hand-and-hand" I just want to clarify that any time the data arrive serially, as in S/PDIF, there must necessarily be buffering of one data point, so that the bits that make up that data point can be reassembled before they are clocked into the DAC. There could also be further delay of up to one sample period to allow the PLL to filter the clock to counteract jitter.

However, when most people talk about "buffering", I don't think this is what comes to mind. To me buffering implies storage of multiple data points between the incoming data and the DAC. This kind of buffereing is totally unnecessary if all you are doing is correcting jitter in data transmission, which will always be a fraction of a bit clock. Correction of gross jitter in the device which is sending the data may require multi-point buffereing, but now you are talking about trying to fix broken hardware. This would also be required if you are sharing bandwidth and have variable latency in transmission.

(Not a) good explanation of jitter in TAS

Reply #88 –
Quote from: Arnold B. Krueger on
There's no reason for a standard DAC to have a crystal. The device sending the digital data either provides a separate but parallel clock signal, or the clock is derived from the input digital data stream. The latter is far and away the most common situation.


You agree that clock recovery from the input stream (S/PDIF, AES/EBU) without a separate word clock is the most common situation. You also agree that jitter correction by buffering requires a crystal (you fill a buffer from a possibly jittered stream and pull from it with a clean clock running at the same average rate) and that most DACs don't have a separate crystal.

Quote from: Arnold B. Krueger on
...it might not seem to be working at all with most modern DACs. They will buffer the signal and make the jitter go away!


So how can "most modern DACs" recover a jittered incoming signal by "buffering" when they don't have a crystal besides employing a PLL?

I agree that jitter is a non issue for common integrated systems such as CD players. But I'm interested how jitter elimination for S/PDIF is supposed to work without re-clocking approaches as ASRC.

(Not a) good explanation of jitter in TAS

Reply #89 –
Quote from: rpp3po on
You also agree that jitter correction by buffering requires a crystal (you fill a buffer from a possibly jittered stream and pull from it with a clean clock running at the same average rate) and that most DACs don't have a separate crystal.

Jitter correction by buffering most definitely does NOT require a separate clock crystal. The control to the PLL in this case would be the amount of data in the buffer. This would allow correcting jitter of much lower frequency than without buffering.

(Not a) good explanation of jitter in TAS

Reply #90 –
Quote from: rpp3po on
Quote from: Arnold B. Krueger on
There's no reason for a standard DAC to have a crystal. The device sending the digital data either provides a separate but parallel clock signal, or the clock is derived from the input digital data stream. The latter is far and away the most common situation.


You agree that clock recovery from the input stream (S/PDIF, AES/EBU) without a separate word clock is the most common situation.


Yes.

Quote
You also agree that jitter correction by buffering requires a crystal


No.

Quote
(you fill a buffer from a possibly jittered stream and pull from it with a clean clock running at the same average rate) and that most DACs don't have a separate crystal.


Yes. One obtains a clean clock from the dirty incoming clock by means something like a PLL.

Quote
Quote from: Arnold B. Krueger on
...it might not seem to be working at all with most modern DACs. They will buffer the signal and make the jitter go away!



So how can "most modern DACs" recover a jittered incoming signal by "buffering" when they don't have a crystal besides employing a PLL?


A PLL is all that is needed.

Quote
I agree that jitter is a non issue for common integrated systems such as CD players. But I'm interested how jitter elimination for S/PDIF is supposed to work without re-clocking approaches as ASRC.


Just clean up the dirty incoming clock. Store the data in a buffer. Build in some latency.  Clock the data out with a cleaned up version of the incoming clock.  Cleaning up dirty clocks has been done effectively for decades.

(Not a) good explanation of jitter in TAS

Reply #91 –
Quote from: pdq on
Jitter correction by buffering most definitely does NOT require a separate clock crystal. The control to the PLL in this case would be the amount of data in the buffer. This would allow correcting jitter of much lower frequency than without buffering.

Agreed.

(Not a) good explanation of jitter in TAS

Reply #92 –
How does one use a PLL to correct for a noisy clock?  My limited use of PLL has been for clocking chips, never noise reduction.  I naively assume that a clock that is feed by an unstable oscillator into a PLL would cause the DAC's clock to very closely follow the unstable clock, but not actually stabilize the frequency.  Do you need to add some filtering or does the PLL handle this directly?

(Not a) good explanation of jitter in TAS

Reply #93 –
All PLLs utilize a loop filter to some degree, to lowpass filter the phase comparator output.

(Not a) good explanation of jitter in TAS

Reply #94 –
Exactly. Long-term, the filtered clock's frequency will be the average of the noisy clock's, but with much less variance from the mean.

(Not a) good explanation of jitter in TAS

Reply #95 –
Ah that makes perfect sense.  Thanks.

(Not a) good explanation of jitter in TAS

Reply #96 –
Thank's all for the feedback! I found this very interesting and read up a little on PLL design. It works exactly as you have described.

Several sources claim, though, that this works only for jitter >10kHz while the most audible jitter would be <10kHz. Wolfson, for example, provides PLL circuits with separate crystals to eliminate jitter down to 100Hz. Are there really crystal-less implementations with comparable performance?

(Not a) good explanation of jitter in TAS

Reply #97 –
Quote from: rpp3po on
Thank's all for the feedback! I found this very interesting and read up a little on PLL design. It works exactly as you have described.

Several sources claim, though, that this works only for jitter >10kHz while the most audible jitter would be <10kHz.


Source?  Link?

My interpretation of such statements is that they are talking about stabilizing jitter without a large buffer to hold data while variations at lower frequencies are being handled.

Quote
Wolfson, for example, provides PLL circuits with separate crystals to eliminate jitter down to 100Hz. Are there really crystal-less implementations with comparable performance?


If you are referring to the following:

"A further benefit of the high performance PLL is the reduction in component count for the overall system. The PLL can be used to synthesise crystal derived clock signals and, without the requirement for any external filter, can operate as a high quality master timing source for the audio system. "

This is a different application than recovering a stable clock from a SP/DIF stream. The application here involves generating stable frequencies from a crystal that are at a wide range of frequencies other than the resonant frequency of the crystal. PLL's are widely used for frequency synthesizers.

(Not a) good explanation of jitter in TAS

Reply #98 –
Quote from: Arnold B. Krueger on
If you are referring to the following:

"A further benefit of the high performance PLL is the reduction in component count for the overall system. The PLL can be used to synthesise crystal derived clock signals and, without the requirement for any external filter, can operate as a high quality master timing source for the audio system. "

This is a different application than recovering a stable clock from a SP/DIF stream. The application here involves generating stable frequencies from a crystal that are at a wide range of frequencies other than the resonant frequency of the crystal. PLL's are widely used for frequency synthesizers.


No, I'm not referring to that. It clearly states the intended application on the same page, which is not mainly frequency synthesis, but suppression of jitter on S/PDIF links with better performance than "traditionally" known from transceivers:

Quote
The transceivers are structured around an integrated high performance PLL with an intrinsic period jitter of 50ps and jitter rejection frequency of 100Hz. Unlike many other transceivers of this type, the WM8804 and WM8805 contribute a negligible level of jitter to the audio system. Traditionally, S/PDIF transceivers can only suppress jitter above 10kHz and have no effect on the low and medium frequencies, which have the greatest impact on audio quality. Crucially, the WM8804 and WM8805 are capable of suppressing these pre-existing timing issues on the signal at frequencies above 100Hz, removing any unwanted audio distortion or problems in this critical audio range.

As an interconnection standard, users and designers have no control over the quality of the S/PDIF inputs into their systems from third parties. The Wolfson PLL technology enables the WM8804 and WM8805 receivers to lock onto and recover the data and timing from poor quality input signals, thereby allowing the transceivers to accept S/PDIF signals from any source, even if the input signal is severely degraded.


Quote from: Arnold B. Krueger on
My interpretation of such statements is that they are talking about stabilizing jitter without a large buffer to hold data while variations at lower frequencies are being handled.


Wolfson doesn't make any claims about improved realtime (very small buffer) behavior, but improved jitter rejection quality. So I can't comprehend that interpretation.

(Not a) good explanation of jitter in TAS

Reply #99 –
The data sheet makes it clear that the chip can be both a transmitter or receiver. As a transmitter, it needs an internal clock, hence the crystal. As a receiver, it synchs to the external data stream and needs no clock of its own.

http://www.wolfsonmicro.com/uploads/docume...8804_Rev4.0.pdf