Going USB

With USB things apparently look the same. Presented to the audio community as flawless (still) new technology, it gained a stream of followers in short term, and we now can relatively safely diagnose this as a trend. Unfortunately, the reasons behind the trend are again a bit outside of the technology and its understanding. Now, however, totally opposite statements regarding performance of this technology can be heard, both those claiming its superiority and flawlessness, as well as those claiming its uselessness for any serious audio purpose. And this applies to the objective technical performance! The mess following its subjective i.e. sonic qualities is even bigger.

Before proceeding further, one additional notice could be useful. Those believing in the ultimate relationship between perceived sound quality of digital audio device and the quality of its clocking scheme (i.e. low sampling jitter), and who really took the “trouble” of thinking about the ways to accomplish the best results in this domain, are probably aware of the plain simple fact: something, at the end of the chain, always must clock the D/A converter, and it is the quality of this clock that determines what you finally get. And to get the best results in this regard, what can be better than the classic, old fashioned, integrated CD player, where the system clock, designed without any constraints and for the ultimate jitter performance, feeds the D/A converter directly, and where everything else is simply synchronized i.e. slaved to it? OK, in fact you don't see such a scheme in the actual CD players regularly, but it doesn't change the point. You can also, if you want, imagine a "CD player" as multi box unit, since this is not about the number of boxes but about the general architecture. (One box is preferred for easier clock routing though.) What does matter is a master clock that is ideally a crystal oscillator that feeds the D/A converter directly. And not the PLL forced to retrieve clock from coded protocols.

It should be further noted that the CD reading process is set up the way it easily corrects for the errors and it hardly and very rarely produces the jitter of its own. Even the “pit jitter” doesn't in fact translate into the "sampling jitter", as shown by Dennis, Dunn and Carson. [1] Jitter possibly associated to the CD transport (as a whole) is rather about the other parts of the chain, and which are anyhow not avoided in any chain: crystal oscillator itself, including its distribution scheme, supply, layout... So, the idea of the PC as advanced or even ideal audio source because “it removes problems of data errors and jitter associated to the CD reading” may be seductive as such but is not really founded in reality.

Having said that, what is S/PDIF, USB, or any other external interface for? "For convenience" is of course the good answer but before proceeding analyzing the current state of performance of USB based digital audio reproduction systems, it is important to understand this: there is nothing that can have that uncompromising clocking scheme, and thus that low jitter, as integrated CD player can. External interfaces do bring convenience but they don't bring improvements in performance. With respect to the performance, they rather bring only additional problems.

The convenience that a PC can offer should not be neglected though, and USB further offers plug 'n' play approach with fair stability in use. (OK, PCs are used, and they will be always used for redundant purposes but that is the other part of the story.) The best USB scheme would be equivalent of the scheme explained above: with system clock placed in the USB D/A device, and PC (i.e. its USB port) slaved to this USB device. A couple of manufacturers claim to utilize such a scheme in their most recent USB audio devices, however, up to this moment no detailed info or performance was published. Anyhow, regularly available USB decoders don't work this way and can not slave the PC; they retrieve a sampling clock from the existing USB stream.

It may look that with this we are at the same problem as we are with S/PDIF but we are not. S/PDIF uses Biphase Mark ("Manchester") coding which embeds the clock into the data, and for this reason its major problem is difficulty to retrieve this clock back, without it being phase modulated by data; in other words, S/PDIF principally suffers of data related jitter.

USB is quite different. It uses Non Return to Zero Inverted (NRZI) coding (to save the bandwidth), which essentially doesn't comprise clock. In some ways, this may make the final results independent from the actual jitter of USB stream. The D/A however normally needs to trigger the output by the clock that is somehow synchronized to the data, and it is on the USB decoder to provide i.e. to recover this clock. In practice, unless USB device is a master device that controls the PC host, requesting the data as needed and according to the speed of own (free running) clock, it will need to recover the clock from the USB stream.

Actual USB decoders do this task more or less successfully, and performances of available USB decoders in reality differ markedly. A short overview will follow.

___________________

[1] Ian Dennis, Julian Dunn and Doug Carson - "The Numerically Identical CD Mystery: A Study in Perception versus Measurement", AES, 1996