I found it funny the explanation given in Stereophile in a review from 1992 to the Linn Karik/Numerik transport/DAC of why not more manufacturers provide clock inputs and outputs. I think Word Clock inputs and outputs should become standard on every transport and DAC, not just the super expensive stuff from dCS, Esoteric etc
In Sync!
The Linn CD player completely sidesteps a problem that plagues all other CD transport/processor combinations: jitter in the recovered clock. Linn's method is so simple I'm surprised no one else has done it before. In fact, I'm surprised that the S/PDIF (Sony/Philips Digital Interface Format) standard didn't incorporate this technique when the interface standard was established. But before looking at Linn's solution, let's see how a conventional transport and D/A converter interface works.
The S/PDIF output of a CD transport—the RCA jack marked "Digital Out"—carries left and right audio information and subcode. All digital transmission must have a clock timing reference, and the S/PDIF signal is no exception. In the S/PDIF format, the clock is embedded in the audio data. (It's actually more accurate to say the audio data are embedded in the clock signal.)
In the digital processor, the S/PDIF receiver chip (usually a Yamaha chip) gets this signal, strips out the subcode and audio data, and generates a new clock based on the incoming clock by using a Phase Locked Loop (PLL) circuit. This clock "recovered" by the PLL then serves as the timing reference for the entire converter. PLLs, however, have an inherent inaccuracy: their operation is based on an error signal and thus they are not perfectly locked to the incoming clock. Further, because the PLL changes the phase of the processor's Voltage Controlled Oscillator (VCO) to match that of the incoming clock, it will attempt to follow jitter components in the transport's data stream. When used in a standard implementation, the ubiquitous Yamaha chip typically generates between two and five nanoseconds (2-5ns) of clock jitter.
The problem arises when the digital words are converted to analog at the D/A converter chips (DACs). The word clock, a subdivision of the master clock signal, tells the DACs when to convert the data word at its input to an analog output signal. Because the clock has jitter, the timing of that conversion will be somewhat in error, the result being that the analog output waveform will be misshapen. Further, clock jitter increases the noise floor and creates sidebands on either side of the audio frequency being processed, the frequencies of which are related to those present in the jitter. These spurious sidebands are not harmonically related to the music and may be responsible for the hash and hardness so often heard from digital audio. The theoretical maximum allowable jitter for a 16-bit word length is 200 picoseconds—about 1/15 the amount of jitter produced by the ubiquitous Yamaha receiver chip.
Note that the amount of jitter and frequency distribution of the jitter create an analog-like variability in the final analog output signal. The argument that digital audio either works perfectly or doesn't work at all—"it's the same ones and zeros"—is a fallacy. I urge you to read JA's superb article on clock jitter starting on p.179 of Vol.13 No.12 (December 1990). It includes a full discussion of this phenomenon as well as graphs of computer simulations of the effects of varying amounts of jitter (footnote 1). The "Industry Update" on the discovery of Logic-Induced Modulation (LIM) in Vol.14 No.9 is also illustrative.
Now, if jitter in the recovered clock is such a problem, isn't there a better way to do it? Yes. The solution is to generate a clean, relatively jitter-free clock in the D/A converter, and force the data source—the CD transport—to lock to this reference. Instead of making the transport the master and the converter the slave, this technique reverses those roles. Instead of sending the clock in the data, the processor sends a clock to the transport on a separate cable.
If the solution's so simple, why doesn't every manufacturer use this technique? One answer may be that processor manufacturers don't include a clock output because no transports have a clock input. Similarly, transport manufacturers don't have a clock input because processor manufacturers don't provide a clock output. Further, there is no standard for what kind of signal the processor should output.
