Jitter: What It Is, and When It Actually Matters

It is a clock problem, not a data problem

The first thing to separate out is that jitter has nothing to do with bits going missing. Digital audio over USB, network or S/PDIF either delivers the sample values intact or fails loudly. The samples in the buffer of a converter are the same numbers that left the file.

What can differ is when each of those numbers is turned into a voltage. Conversion is triggered by a clock, and if the clock's edges are not perfectly evenly spaced then samples are reproduced slightly early or slightly late. A value that was correct for one instant is emitted at a different one, and the error that introduces is real analogue distortion.

That is the whole mechanism. It also explains why jitter cannot be fixed downstream: once the conversion has happened at the wrong moment, the error is in the analogue signal.

The arithmetic that sets the scale

For a sine wave, an error of Δt in timing produces an error in amplitude proportional to the slope of the wave at that point. Work it through and the error relative to the signal comes out as 2 x pi x f x Δt, where f is the frequency of the tone.

That formula is worth putting numbers into, because it settles most arguments on its own.

One nanosecond of jitter on a 1 kHz tone gives an error about 104 dB below the signal. The same nanosecond on a 10 kHz tone gives an error about 84 dB down, because the waveform is changing ten times faster. Reduce the jitter to 100 picoseconds and that 10 kHz figure drops to about 104 dB down; at 10 picoseconds it is around 124 dB down.

Two things follow. Jitter matters more at high frequencies, rising at 6 dB per octave, which is why its audible signature is described as a loss of focus in the treble rather than a change in the bass. And picoseconds, not nanoseconds, is the unit that decides whether it is relevant, which is exactly the range competent modern converters operate in.

Where it can enter the chain

Only at the conversion clock, so the question for any input is simple: does the timing of the incoming signal reach that clock?

With asynchronous USB, it does not. The converter's own oscillator is the master, the computer is told how fast to send data, and the samples sit in a buffer until the local clock calls for them. The source's timing is discarded by design. This is why asynchronous USB was a genuine advance and why arguments about the timing quality of a USB cable have a much weaker mechanism behind them than they did before it existed.

With S/PDIF, coaxial or optical, it can. The clock is embedded in the data stream and the receiving converter recovers it, so waveform degradation in the cable or a noisy transport output can translate into timing error at the point of conversion. This is the one place in a modern chain where transport and cable claims have a defensible physical basis, and it is why converters that buffer and reclock their S/PDIF inputs behave more consistently across sources than those that do not.

I²S carries the clock on its own conductors rather than embedding it, which removes the recovery step, and is why the connection shows up on separates that are designed to be used together.

What it does and does not sound like

Jitter is correlated with the signal, so it appears as sidebands around a tone rather than as broadband hiss. That is what a J-test measurement shows: a single tone, and skirts around it whose height and spacing describe the timing error.

The honest position on audibility is that in a competently designed converter the sidebands sit far below the noise floor of the recording being played, and the published thresholds for hearing random jitter on music are orders of magnitude above what such a converter produces. It is a solved problem in good designs and a real one in bad ones, and the interesting cases are all in the second group.

What is worth spending on

A converter with a good local clock and an asynchronous input solves this at the source, and that is the whole of the answer for most systems. A reclocking device earns its place when something upstream is fixed and imperfect: a streamer with only an optical output, a legacy transport, a long coaxial run. Adding one in front of an already asynchronous USB input is solving a problem that input already removed.

Settling it in your own system

If you think you can hear a difference between two digital sources, this is one of the easiest claims in audio to test properly, because both can usually be captured or switched at matched level. The blind test below runs the comparison for you and produces a result you can keep. A difference that survives it is a difference. One that does not has told you something more useful than another opinion would have.