Jitter question Options

[doomlordis]

I know (roughly) how jitter is created when converting digital to analogue due to clock timing errors/disc read errors on cd players but do/can Daps (Digital Audio Players) suffer from the same issue?

This post has been edited by doomlordis: May 16 2008, 14:05

[cabbagerat]

I know (roughly) how jitter is created when converting digital to analogue due to clock timing errors/disc read errors on cd players but do/can Daps (Digital Audio Players) suffer from the same issue?

Jitter (as in time interval error) can be present in any digital signal clocked by an imperfect clock, and thus can certainly happen on the output of DAPs. There is quite a lot of nice info on Jitter available on the web - I would recommend you start at http://www.tektronix.com/jitter/.

[pdq]

I know (roughly) how jitter is created when converting digital to analogue due to clock timing errors/disc read errors on cd players but do/can Daps (Digital Audio Players) suffer from the same issue?

I don't believe that disc read errors can cause jitter, since the data read from the disc are buffered before being sent to the DAC.

[greynol]

I think the term jitter has been hijacked by the DAE community. Kind of like classifying a tomato as a vegetable.

[Roseval]

Maybe this link is of use: http://www.jitter.de/english/engc_navfr.html

[pdq]

The irony is that people go on and on about the jitter in digital signals, but rave about analog recording and playback, when the truth is that the jitter in a half-decent crystal oscillator is probably orders of magnitude smaller than the wow and flutter in turntables and tape decks.

[knutinh]

The irony is that people go on and on about the jitter in digital signals, but rave about analog recording and playback, when the truth is that the jitter in a half-decent crystal oscillator is probably orders of magnitude smaller than the wow and flutter in turntables and tape decks.

I was under the impression that frequency content plays a major role along with amplitude of the jitter. Comparing two very different jitter-sources in terms of audible degradation is probably hard without doing real listening tests.

-k

[Woodinville]

Jitter, in the sense of noise in the sampling rate, is required by physics. All systems can and will have some. The art and engineering is in making it less, and of a less offensive spectrum.

Jitter, in this sense, is irregularities in the sampling intervals.

[Kees de Visser]

Woodinville, do you have an explanation for the huge difference between jitter levels that are claimed (by anecdotal evidence) to be audible and the ones that have been found in controlled tests ?
Many audio (recording/mixing/mastering) engineers claim jitter artifacts to be audible down to the low picosecond level. The scientific jitter tests I know of (e.g. Dolby and Ashihara) seem to conclude that mid nanosecond level (which is 1000 times higher!) is the limit of what can be heard. Wouldn't a test have to be extremely flawed in order to produce such a difference ?

[Woodinville]

Woodinville, do you have an explanation for the huge difference between jitter levels that are claimed (by anecdotal evidence) to be audible and the ones that have been found in controlled tests ?
Many audio (recording/mixing/mastering) engineers claim jitter artifacts to be audible down to the low picosecond level. The scientific jitter tests I know of (e.g. Dolby and Ashihara) seem to conclude that mid nanosecond level (which is 1000 times higher!) is the limit of what can be heard. Wouldn't a test have to be extremely flawed in order to produce such a difference ?

The audible difference from jitter depends enormously on two things, the actual input signal, and the spectrum of the jitter.

any test that does not report both means nothing.

[Kees de Visser]

The audible difference from jitter depends enormously on two things, the actual input signal, and the spectrum of the jitter.

Any suggestions for both ingredients for a worst case scenario ?

[Woodinville]

The audible difference from jitter depends enormously on two things, the actual input signal, and the spectrum of the jitter.

Any suggestions for both ingredients for a worst case scenario ?

Well, for the audio signal, the higher the slew rate (derivitive) the worse the effect, in an f^2 sort of way.

So in that respect, a 19kHz sine wave would be a good "signal" not that any sane person would listen to it.

For the jitter, while one could propose a 17kHz tone jitter, that's cheating massively. Broadband (many times FS/2) jitter will all get folded down, perhaps is also a bad case.

It would also be possible to figure out a sinusoidal jitter frequency and high frequency taht would put everl alias at 2kHz, or something like that, too, I supose, although I haven't tried, but the word "contrived" is very nearly an understatement.

[hellokeith]

Jitter, in the sense of noise in the sampling rate, is required by physics. All systems can and will have some. The art and engineering is in making it less, and of a less offensive spectrum.

Jitter, in this sense, is irregularities in the sampling intervals.

Is there a natural phenomenon which can be used to synchronize both the sampling and the playback? Kind of like how a meter is defined?

I have this picture in my mind of some sort of electronic clock source which drives a metronome that the drummer or musician listens to while playing live in the studio being recorded, while that clock source also is used to time the sampling equipment. And finally, that same clock source is used to time the DAC on playback.

[AndyH-ha]

A good clock is at the heart of every ADC and DAC. Any irregularity in the clock upon sampling means that the sample was taken at the wrong time, either too early or two late, relative to when the perfect clock would have captured it.

Since this is a random irregularity, there is no way to know which samples, whether they were early or late, or how much difference there is between the actual and the should-have-been. Thus there is no way to correct the error (the correct sample does not exist) or compensate for it. This effects both recording and playback but is generally too small for anyone to notice, is spite of many weird ideas about it in the "audiophile community."

Timing interval problems of various lengths can occur anyplace else in the recording or playback chain but are irrelevant (unless they are catastrophic). Suppose after the sample is taken, there is a glitch further on in the chain that alters the timing significantly. The samples are simply being recorded, a string of numbers, so that glitch is totally lost by the time the sample is put to bed. It isn't part of any information that is stored.

On playback, any timing variations that occur on the way to the DAC are easily corrected by having the samples buffered and reclocked just before conversion to analogue. No information about those variations is retained. The DAC clock itself has some jitter, just like in the ADC, but in any decent equipment, it isn't enough to matter.

[cabbagerat]

I have this picture in my mind of some sort of electronic clock source which drives a metronome that the drummer or musician listens to while playing live in the studio being recorded, while that clock source also is used to time the sampling equipment. And finally, that same clock source is used to time the DAC on playback.

I would love to see a picosecond accurate drummer The idea is not entirely without merit, however. If you replaced the ADC and DAC timing sources with (say) GPS disciplined ovenized crystal oscillators, you could (theoretically) improve the SNR of the system. Theoretically.

Woodinville, would it be accurate to say that as long as the error due to jitter is much smaller than the quantization noise (or dither) it can't be audible (with an ADC, at least)? Just off the back of an envelope, say we have a 16 bit system, with a sampling rate of 44.1kHz, the time interval error would need to be at least ~1.5ns to flip the LSB given a 22kHz sinusoid.

[Roseval]

If I understand the rather complex phenomenon of jitter correctly, the problem is not the bit flipping. This can happen but then is must be very severe and will be clearly audible (clicks).
In practice jitter will raise the noise floor and causes sidebands. Whether this is audible depends also on the type of DAC used.
Maybe this link is of use: http://thewelltemperedcomputer.com/KB/BitPerfectJitter.htm

[tot]

This white paper might also be quite useful to understand the effects of the jitter. Mind you, it is written by a DAC manufacturer.

[cabbagerat]

If I understand the rather complex phenomenon of jitter correctly, the problem is not the bit flipping. This can happen but then is must be very severe and will be clearly audible (clicks).
In practice jitter will raise the noise floor and causes sidebands. Whether this is audible depends also on the type of DAC used.
Maybe this link is of use: http://thewelltemperedcomputer.com/KB/BitPerfectJitter.htm

I should have made it more clear that I was referring to an A/D, not a D/A. In an A/D, as long as the bits coming out are the same, then (obviously) jitter is having no effect whatsoever. The diagram on page 6 of Lavry's white paper clearly shows how jitter sidebands are destroyed by quantization. Note that those diagrams show something of a "worst case" - very narrow band jitter.

This white paper might also be quite useful to understand the effects of the jitter. Mind you, it is written by a DAC manufacturer.

The paper is interesting, but the choice of jitter spectra isn't really realistic, in my opinion. Certainly worth a read.

[knutinh]

I should have made it more clear that I was referring to an A/D, not a D/A. In an A/D, as long as the bits coming out are the same, then (obviously) jitter is having no effect whatsoever. The diagram on page 6 of Lavry's white paper clearly shows how jitter sidebands are destroyed by quantization. Note that those diagrams show something of a "worst case" - very narrow band jitter.

But perhaps the case of D/A-converters is more interesting? What is the best manufacturer-supplied measurement to get a first-order impression of jitter-performance, jitter-suppression of a given device?thd+n?

How deep must (any) analog signal be buried in analog noise before one can say with confidence that a human listener cannot distinguish it?

-k

This post has been edited by knutinh: Jul 2 2008, 08:17

[Woodinville]

I should have made it more clear that I was referring to an A/D, not a D/A. In an A/D, as long as the bits coming out are the same, then (obviously) jitter is having no effect whatsoever.

Well, it is quite unlikely that the bits coming out of the ADC will be the same in all cases if any jitter whatsoever exists. So I'm not quite sure what you're arguing here.

The question of when you take the sample for the ADC is the issue, and the amplitude error is proportional to the amount of jitter AND to the slew rate of the signal.

[pdq]

Well my back-of-the envelope calculation says that for 1 nSec RMS of jitter on a 20 kHz sine wave the SNR is roughly 75 dB, proportionately less for lower frequencies. Is this audible?

Edit: Proportionally higher SNR for lower frequencies.

This post has been edited by pdq: Jul 2 2008, 12:19

[cabbagerat]

I should have made it more clear that I was referring to an A/D, not a D/A. In an A/D, as long as the bits coming out are the same, then (obviously) jitter is having no effect whatsoever.

Well, it is quite unlikely that the bits coming out of the ADC will be the same in all cases if any jitter whatsoever exists. So I'm not quite sure what you're arguing here.

All I am arguing is that as the jitter reaches some limit, it's effects on the A/D process will disappears below the quantization noise. This is accepted in the literature, so I wasn't really arguing it - more stating that there will be a lower limit where the jitter effects do not cause the bit stream to be different. Above this limit, whether the jitter effect is audible will depend on (as you said earlier in this thread) the amount of jitter, the jitter spectrum and the signal itself. The literature puts this limit at around or above 20ns RMS for typical music signals - not the handful of picoseconds claimed by some people.

We seem to be in agreement here, so maybe I was creating controversy where there is none.

[Woodinville]

All I am arguing is that as the jitter reaches some limit, it's effects on the A/D process will disappears below the quantization noise.

Ok, that's not what it looked like you said. Said amount of jitter, by the way, is exceptionally small, and very unlikely to ever be seen in practice in most devices.

The literature puts this limit at around or above 20ns RMS for typical music signals - not the handful of picoseconds claimed by some people.

Well, if you look at the size of the smallest step (normalized to 1) times the maximum slew rate of an input signal, you can directly calculate the jitter level equal to the smallest step size

[cabbagerat]

Well, if you look at the size of the smallest step (normalized to 1) times the maximum slew rate of an input signal, you can directly calculate the jitter level equal to the smallest step size

Ok, so the maximum slew rate for a 22kHz sine sampled with 16bits is about 9.0e9 quantization steps per second, and therefore peak jitter below ~0.1ns will not cause a bit to flip. Similarly, about 0.5ps for 24bits. Does that sound sensible?

I put together some quick and dirty MATLAB code to attempt to simulate the effects on jitter in an ADC. It has a whole pile of shortcomings, but still gives some interesting results. The code should work unaltered in GNU Octave 2 and 3.

CODE

% Approximately simulate the effects of jitter on a signal
% x - Original (unquantized) samples
% fs - Sample rate
% rmsjitter - RMS jitter value (seconds)
% bits - Number of bits
% jy - Quantized signal with simulated jitter
% qy - Quantized original signal
function [jy qy] = simulatejitter(x, fs, rmsjitter, bits)
    lx = length(x);
    jitter = randn(1, lx)*rmsjitter*fs; % Jitter in samples, white gaussian
    y = zeros(size(x));
    for ii = 1:lx
        for jj = 1:lx
            y(ii) = y(ii)+x(jj)*sinc((ii-jj)+jitter(ii));
        end;
    end;
    % Quantize to the given number of bits
    jy = quantize(y, bits);
    qy = quantize(x, bits);
end
    
function q = quantize(s, bits)
    step = 2^(bits-1);
    q = round(s*step)/step;
end

[Woodinville]

Well, if you look at the size of the smallest step (normalized to 1) times the maximum slew rate of an input signal, you can directly calculate the jitter level equal to the smallest step size

Ok, so the maximum slew rate for a 22kHz sine sampled with 16bits is about 9.0e9 quantization steps per second, and therefore peak jitter below ~0.1ns will not cause a bit to flip. Similarly, about 0.5ps for 24bits. Does that sound sensible?

The jitter energy will be the same as the quantization energy, perhaps modulo a normalization for the distribution factor that I don't know if you hit or not.

BUT this will still sometimes flip bits.

Don't forget, if the signal is 1 part in 10 zillion (sic) below a threshold, and going up fast, and the sample is just ->||<- late, it will flip to the next quantization level. That's a much harder problem, to say the least.