DIGITabilis: crash course on digital audio interfaces

An Introduction - Part 1.2

Jitter and the separate DAC

As we have seen in Part 1, the solution for the virtual elimination of jitter in integrated CD players the solution is strightforward, even though at a cost.

In the case of separates, with the transport in a box and the DAC in another it is now clear that it is necessary to supply the DAC with a clock as clean as possible.

It is obvious that the better the clock from the transport, the better the reconstructed clock at the DAC. A very simple and very cheap way to get a better signal from a transport is to re-clock the S/PDIF flow just before it leaves the transport with the cleanest available clock. This allows achieving the best possible results with a very low cost.

Unfortunately, this last, not so expensive solution does not solve all the jitter problems with separate units.

As a matter of fact, there is a structural problem in the interface, as the biphase-mark code used causes interference between data and clock information: that is, the clock information is in some way mixed up, polluted and confused by the data, and any reconstructed clock suffers of data dependent jitter!

Well spotted, digital audio industry! A little late, but better than never, isn't it?

And so HiEnd (because implementation costs are not sustainable in a low cost design) started inventing any possible alternate solution to this problem.

First of all, the standard PLL (phase locked loop) systems used by the standard receivers to retrieve the clock are recognized as not good enough for high end audio: often a second, much more tight and stable PLL, based on a voltage controlled crystal oscillator (VCXO) is added after the receiver just to utterly stabilize the clock. This apparently obvious solution, if correctly implemented, can give in facts outstanding results without a huge complexity and without the need for a non-standard interface architecture. The cost of a good implementation is however not low at all.

The second simplest approach is to transmit the clock separately. This solution already goes out of the consumer standards, even though it is normally used in professional environment, where it is necessary to keep many different cards and units perfectly synchronized. As a consequence, a few different proprietary solutions based on the same concept were proposed.

A rather special implementation recently adopted (by NorthStar, for example) is to extend the I2S interface outside the transport through a multi wire interconnect to the DAC unit. This has a further benefit, in that it does not require any S/PDIF transmitter and receiver at all, but only a simple array of line driver and receivers, and all the circuit can be far simpler. Unfortunately no standard has been defined, and each implementation is therefore quite different.

The first general issue this interface had to face is incompatibility with the international consumer standard. In facts, this was not a problem on the transport side, where it is simply necessary to have a secondary digital output connection with the pure clock signal.

On the DAC side, instead, it is normally assumed that the unit has to work also with a standard connection, which is retrieving the clock from the SPDIF flow. In practice, the external clock input is enabled or disabled, depending on the partnering transport. This obviously adds some complexity to the clock circuits, even because the mode selection is often completely automatic and based on the recognition of a clock signal at the clock input. This added complexity in some extent can endanger the clock purity.

There is, in any case, a further major disadvantage, in this configuration.

Now, transferring the clock from another unit through a couple of pulse transformers, two couples of connectors, a cable subject to RF interferences and ground loops, is definitely not the best way to keep it clean...

The solution proposed by a few companies (Wadia and Sonic Frontiers, between the others) is to move the master clock where the cleanest clock is needed: that is, in the DAC unit.

In this configuration the transport is receiving a degraded, possibly jitter affected, copy of the clock. But given the fact that the only job of the transport is to provide a flow synchronous with the DAC clock, while clock precision can be assured simply by re-clocking the signal just before entering the DAC, the transport jitter causes no problem at all, unless it causes digital transmission errors.

Obviously, this solves a major issue, but also makes both the DAC and the transport something functionally rather different from their normal structure. Better, takes the concept of the transport and of the DAC back to the origins, building up something very similar to an integrated CD player in two boxes.

Again, the problems are connected with compatibility: both the transport and DAC units must implement both the standard behaviour, with the Transport as master connected through SPDIF to a slave DAC, and the new concept, with the DAC master and the Transport slave. Lot of added complexity again, and corresponding price tags: neither Wadia nor Sonic Frontiers are famous for selling cheap units, isn't it?

There was also someone who moved one step further. Linn, after studying the problem, decided that transferring the clock back caused too much RF interference, and implemented as a consequence a slightly different system.

To avoid transferring a high frequency signal, and taking into account that the S/PDIF flow transports even clock information that is made available in the DAC by the receiver, they decided to synchronize the transport using what could be defined as a "distributed phase locked loop (PLL)".

In facts, apparently (Linn is not so available to disclose the technical aspects of their products) they add in the transport a second, voltage controlled oscillator (VCO) to provide a local clock, and a phase detector in the DAC. The phase detector constantly compares the phase of the extracted S/PDIF clock with the local master one, and sends back to the transport a control signal proportional to the phase difference between the two clocks. If the VCO slows down, then the phase difference increases, and the control signal forces the VCO to run faster, recovering the desired phase angle. This is exactly the normal structure of a PLL, and the only (not minor, indeed) peculiarity is that the two parts of the circuit are placed in different boxes!

The interconnects

All discussions up to this time have never taken into account how the connection between the two units is implemented. And the reason is that the transmission support is widely irrelevant for most of the discussions above.

There are however some remarkable differences between the various standards, and we will (marginally) address them in the next lines.

As you all probably know, there are three main connections types used in Digital audio.

The first two, S/PDIF and AES/EBU electrical standards, are electrical connections, that is electrical wires with very specific characteristics and terminations.

S/PDIF standard connection (the consumer standard, by the way) is a 75 ohm coaxial wire (RG59, for example) terminated with RCA pin male connectors. Unfortunately, almost no one certifies RCA pins for a precise 75ohm impedance, so quite a few high level producers prefer to use BNC connectors, that are widely used in labs even at high frequencies and can be found with a precise 75ohm impedance; note that these connectors are out of the standard... but probably work better than the standard ones.

AES/EBU, the professional standard, uses a balanced shielded connection with impedance of 110ohm terminated with balanced XLR 3 pin connectors.

A note about an aspect I did not explained in advance: S/PDIF and AES/EBU flows have an identical structure, but the content of a few service bits in the flow is different: therefore using a balanced connector on an S/PDIF flow does not make this an AES/EBU flow.

The last connection type is the optical one. The optical connection used in consumer audio is the so called TOSLINK, name derived from the fact that it was proposed by Toshiba.

In this connection the transmission media is a plastic (or even glass, in the best cases) optical fibre. The transmitter is just a red led, while the receiver is a light sensitive circuit. The signal is transmitted in agreement with the S/PDIF standard coding.

There also is another optical connection type, named ST, but it is not so common.

For what regards electrical connections, S/PDIF is the simplest and the lowest cost solution, not requiring a transformer at both ends. It is also the least effective, as there is scarcely any isolation between the two systems, and the shield can be subject to ground loop currents, while does not achieve an adequate level of protection from RF interference. AES/EBU is more expensive, but definitely better under all these aspects.

Comparison of Toslink and electrical connections is less easy. In facts, Toslink is said to cause a high level of jitter in the transmission, and from measures (2ns peak jitter) appeared very recently on DIY Audio.com it seems to be definitely true (even though in AES paper there are references to 30ns peak jitter...). It is not clear, anyway, which is the spectral content of the jitter, as it is well known that most of high frequency jitter can be eliminated by the SPDIF receiver.

On the other side, optical connections achieve perfect electrical isolation between the different units, and from this point of view they are definitely much better than any other connection.

Now the big question: how much a digital interconnect can influence the sound of transport + dac couple? IMHO I can just say that the influence of digital cables on sound is far, far heavier than anyone could expect! So, we will discuss the issue too in a specific article.

For a further discussion of SPDIF interface, please refer to the article S/PDIF Interface by Tomi Engdahl which, even though is not really at the basis of this article, has proved very very useful so many times for implementation details and ideas.

Conclusions

This article is just a brief discussion of the possible ways to implement or enhance a digital interconnection between a transport and a DAC. More and more solutions (USB, FireWire,.. ) are getting available, but the quality they can achieve is all to be still proved. In the meanwhile, this is what has been made available for high quality digital sound connections.

Rewind to: [Part 1.1] | Fast forward to: [Part 1.3] | [Part 1.4] | [Part 1.5]