A Transport of Delight: CD Transport Jitter Page 2

The block diagram of fig.1 shows how transport jitter ends up in the digital processor's word clock. The call-out numbers in fig.1 correspond to the five jitter sources described above. Fig.1 shows why transports and digital interfaces sound different—their jitter directly affects the timing precision of the digital/analog conversion process.

Fig.1 Jitter sources in a CD playback system

The "bits is bits" camp rejects this thesis, claiming that transport and interface jitter is completely removed by the digital processor's input receiver. They consider the PLL an absolute barrier to jitter. Consequently, they argue, transports, digital interfaces, and CD tweaks can't affect sound quality.

I conducted a little experiment to test this hypothesis. I measured a digital processor's word-clock jitter (with the Meitner LIM Detector described in Vol.16 No.1) when driven by two different digital sources. One source has low jitter (the PS Audio Lambda transport), and one source has high jitter (the Panasonic SV-3700 professional DAT machine). Fig.2 shows the jitter spectrum of the processor's word clock when driven by the Lambda. For contrast, fig.3 is the same processor's jitter spectrum—measured at the DAC with the identical test signal and conditions—but with the high-jitter Panasonic SV-3700 driving the processor. Note the vastly cleaner spectrum and fewer discrete-frequency jitter components when the processor was driven by the Lambda. Moreover, the overall RMS jitter (measured from 400Hz to 22kHz) increased from 145ps with the Lambda transport to a whopping 561ps when driven by the high-jitter SV-3700. Clearly, jitter in the S/PDIF signal driving a digital processor does greatly affect word-clock jitter inside the processor.

Fig.2 PS Audio Reference Link, DAC word-clock jitter spectrum, DC-20kHz, when driven by PS Audio Lambda CD transport (linear freqeuncy scale, 10dB/vertical/div., 0dB = 1ns.) RMS jitter (400Hz-22kHz) = 145ps.

Fig.3 PS Audio Reference Link, DAC word-clock jitter spectrum, DC-20kHz, when driven by Panasonic SV-3700 DAT recorder (linear freqeuncy scale, 10dB/vertical/div., 0dB = 1ns.) RMS jitter (400Hz-22kHz) = 561ps.

Incidentally, the digital processor used in this experiment was the PS Audio Reference Link, which uses the Crystal CS8412 input receiver in perhaps the best possible implementation. The difference would have been even more dramatic if I'd chosen a processor with the Yamaha YM3623 chip, or one that had a lower-quality implementation of the CS8412. Note that these measurements don't reflect poorly on the Reference Link: any processor with the Yamaha or Crystal input receiver (ie, just about all of them) will pass these differences in transport jitter to the recovered DAC word clock (footnote 3).

Because a processor's clock jitter changes so dramatically when driven by different digital sources, some important questions are raised about how jitter is specified in digital processors. First, when digital-processor manufacturers quote jitter numbers in their literature, what transport or digital source do they use? With what test signals? And over what measurement bandwidth? Finally, what test instrument do they use to measure jitter? It's too easy for manufacturers to offhandedly claim a low jitter number without even knowing what the jitter levels or characteristics really are. Be suspicious of any jitter claims made in manufacturer's specification sheets and promotional literature.

As clearly demonstrated in the experiment described above, transport and interface jitter end up at the DAC's word clock—the point where jitter affects sound quality.

Test methodology
Using the UltraAnalog jitter analyzer is simple. A CD transport or other digital source is connected to the analyzer's input, and the analyzer's output is fed to an Audio Precision System One. The System One is configured to perform a 1/3-octave spectral analysis of the transport's jitter. This technique plots the jitter's energy as a function of frequency in 1/3-octave bands from 20Hz to 50kHz. This is exactly the same technique we use to look at a processor's output when decoding a 1kHz, -90dB dithered sinewave in all our CD-player and digital-processor reviews.

After the spectral analysis is performed, the overall RMS jitter amplitude is measured using the System One. The System One's bandpass filters are invoked to band-limit the measurement to 10Hz-30kHz. The measured RMS voltage of the jitter energy in the 10Hz-30kHz band indicates the transport's RMS jitter level, expressed as a single number in picoseconds (the analyzer is calibrated at 100mV per nanosecond). We thus end up both with a spectrum of the jitter and a number that reveals the "area under the curve" of that spectrum.

Because the jitter analyzer doesn't have optical inputs, the measurements were restricted to coaxial and AES/EBU outputs. The transports' AES/EBU outputs generally had lower jitter than their S/PDIF outputs. In some cases there was little or no difference; in other products—the Meridian CDR and SV-3700, for example—the jitter was significantly lower from the AES/EBU jacks (footnote 4). Except for the SV-3700, which was chosen to illustrate a poorly implemented S/PDIF interface, I chose the lower-jitter AES/EBU measurements for presentation.

The test terrain
Selecting appropriate test signals is difficult for any measurement, never mind one as new as transport jitter. We settled on showing two graphs for each transport: one made using three test signals, and one made with two musical selections. The test signals were all taken from the CBS Test CD: digital silence (all data words are zero); a 1kHz sinewave at full-scale; and a 1kHz sinewave at -90dBFS. I tried other test signals—intermodulation twin tones and squarewaves, for example—but decided to publish only the three signal conditions (no signal, very low-level signal, and very high-level signal) to keep the graphs from getting too cluttered.

The musical selections were chosen for their very different signals and levels. Music #1 (the solid trace in all the music plots) was the first minute and a half of Stravinsky's The Firebird Suite on Sheffield Lab CD-24. The levels are extremely low (about -35dB) at the beginning of this disc: the signal is mostly ambience and noise, with instruments playing very softly. The second musical selection (the dotted trace in the graphs) was chosen for its opposite signal characteristics. "Cut to the Chase," from Steve Morse's Southern Steel (MCA MCAD-1-112), begins with the levels at almost full-scale and stays there for the whole piece. Most music falls somewhere between these extremes.

Footnote 3: Note that the Meitner LIM Detector measures jitter up to 20kHz, but jitter up to 40kHz can affect sound quality. Further, the LIM Detector's 20kHz bandwidth won't show the jitter attenuation above 25kHz provided by the Crystal CS8412 chip. However, the figures presented reveal that the CS8412 is virtually transparent to jitter energy below 20kHz.—Robert Harley

Footnote 4: This suggests that how well a particular interface is implemented is more important than the interface (S/PDIF or AES/EBU) itself.—Robert Harley

Share | |
p_f_m's picture

Hi, first of all thank you very much for doing this. It is very informative and I appreciate your time and efforts you spent on this. I do have a couple of questions though -

For the audibility tests, did you test the players/sources using the same outboard dac via spdif ? or were you listening to the analog outputs of the playback sources ?

Comparing the worst v/s the best is a great way of highlighting the differences and to educate users how jitter sounds like, however I feel it would have been perfect, especially after having spent the time and effort to come this far anyway, if you could have also thrown in to the listening test one or two players that had "average" or not too bad or good jitter. This would have kind of helped understand approximately whereabouts might be the threshold of audibility of jitter.

Thank you! and looking forward to hearing from you.


Enter your Stereophile.com username.
Enter the password that accompanies your username.