DIGITabilis: crash course on digital audio interfaces

An Introduction - Part 1.1

Foreword

After designing a few DACs, I started thinking about further enhancements that could be undertaken. I already had some experience with high level transport units and low jitter clocks, and also already had a CD player that was set-up specifically for this kind of tests. Now the next obvious step was to try to go further.

I started gathering all kind of information over the net, and indeed a lot was available there.

Unfortunately, the technical aspects were often presented with so much marketing hype, that they became very suspect from any technical point of view. When I happen to read that "the solution XY implemented by our company is the best in the world, because this and that", well, then I tend to assume that there might be something interesting indeed in the this and that, but no solution can reasonably claim to be the absolute best in such a complicated world, unless perhaps it is the only one.

And in this specific case we'll see very soon that the available solutions are many, even though most of them are not so widely used...

The problem was at this point to try to gather some serious information and possibly test results relative to this entire world. And it was a serious problem, because research labs either publish the results in the JAES (Journal of Audio Engineering Society) or as paper presented at AES conventions, or keep most of the information reserved.

I just realized that the amount of available info is much reduced when I started searching information in the AES files regarding tonearms: most information dates back years and years, and the most recent ones seem definitely of secondary importance: but this does not match at all with the hype on research of many companies, so either these are just pretending to invest in R&D, or they are keeping even the smallest piece of info reserved as competitive advantage. Well, in facts, it might well be the first: nothing remains secret longer than what does not exists at all...).

So in the end I tried to see if with my poor lab instrumentation, recently reinforced by some extravagant investment (OK, OK, some very minor investment... ) I could get some useful information.

The search is becoming rather wide, as while I was working around all this matter, a friend asked me to test his clocks, and I already had two other clocks available; at the same time Lucio had a whole bunch of digital interconnects to test, and we thought that it would have been very interesting to try to match the technical test results with the listening tests, in a half blind way.

And while study and testing goes on, always new facts and starting points are found. So in the end this, that should have been a mini-series of two or three articles, is developing into a soap opera.

In the next articles of theses "Digital Interfaces" series we plan to present a few high quality clocks, to present the implementation of a few of the listed solutions and to discuss digital interconnects technical parameters and sound.

A really simple and easy program, isn't it? Yes, we know, lack of ambition is our greatest fault... ;-)))

A very brief introduction to the CD player structure

Just to make the next paragraphs clear to everyone, I would like to clarify some basic points on the structure of a CD player.

The CD player can be seen, at very high level, as built up of two major components: a transport, which takes care of reading the digital data from the CD, and a D/A converter, which takes care of the conversion of digital data into analog music (or possibly noise...).

The two sub-units are synchronized by a single master clock, which drives both of them: that is, data are read out of the CD, transferred to the D/A converter and converted into music according to the pace stated by this master clock. Other derived clock info (bit clock, word clock, lrclock, depending on the specific chips used) are transferred from the transport sub-unit to the D/A converter, but are in any case synchronous with the master clock.

In facts, while the CD contains the music information, the rate with which this information must be transformed into music is a pre-defined, fixed standard, depending only on the type of support (CD, DVD, SACD) and the track or layer selected. Much alike the turntable, by the way: the reproduction speed, at least in the recent decades, was standardized at 33 1/3 or 45 RPM.

By the way, there is a major difference between turntable and CD speed: while the vinyl record is to be read at a constant rotational speed, the CD must be read at a constant linear speed: that is, while the turntable rotates always at the same RPM, whichever the position of the pickup on the record, the CD player rotates slower when the laser pickup is in the inner areas than when it is in the outer. This means that, in order to supply a perfectly stable and constant data flow, it is necessary to control the speed of the player spinning motor through sophisticated systems. The motor in turn can absorb high current pulses when a sudden speed correction is required, causing a great part of the EMI pollution in a CD player.

In integrated CD players, the master clock is normally placed near the DAC circuits, and for very good reasons, as we'll see. When the transport is designed also for stand-alone operation, however, often it can be instead found directly on the transport board (e.g. Philips CD Pro2 and all the CD ROM readers: in both cases, however, there is also a "service" DAC on board).

S/PDIF and her 40 sons

The basic point of a digital audio streaming interface, is the fact that it is necessary to transfer across the gap not only the basic sound information, that is the digitalized sound samples, but also the pace of the conversion, the clock.

This simple matter of fact, combined with the need of a very simple and inexpensive communication channel, led industry to define a single line interface. This, known initially as S/PDIF (Sony/Philips DIgital InterFace), was obviously proposed by the companies that "invented" the CD at the beginning of digital sound era.

The interface uses a special code, named biphase-mark. In this code any bit is transmitted by a sequence of two half bits, but the combination rule is such that there must always be at least one transition (from low to high or vice versa) for each transmitted bit. This allows, as is immediately clear, to transfer not only the data content, but also precise clock information.

Similar codes are widely used with the highest satisfaction in many applications (typically in telephone and computer networking). As such, at the time of their introduction they appeared to be the ideal solution.

So the data flow is transferred from the transport subunit to an audio transmitter that, based on the local clock, encodes the data stream and sends it to the DAC.

At the DAC side an audio receiver (CS8414, for example) receives the data flow, extracts the clock and decodes the data.

Both S/PDIF and the very similar AES/EBU interface, used normally in professional systems on balanced interconnects, have been accepted as international standards under the name IEC958. These standards have been later extended in several directions (higher speed, more bits, more audio channels, and so on) and the whole matter is now regulated by IEC60958 norms.

However, digital audio proved to be affected by other problems, further than the drilling sound typical of the first CDs ("Oh, listen, now this sound is really clean and transparent..!"): some time information is not perfectly correct, there is a strange effect that in some extent is similar to the well known wow and flutter of tapes and (in a far lower extent) turntables, but is even more annoying and tiring than the usual.

The problem is due to the underestimated (by the digital audio developers) capability of human brain to perceive even the smallest variations in the rhythm of music, to an unbelievable extent. The technical problem at the basis of all this is jitter, which is the instability of the pace of a clock or a signal: even the crystal clocks, which can be considered perfectly stable for any kind of application (just think of watches...), are beaten up by the human ear.

Note that jitter is a very well known digital communication problem, indeed, but at least for what regards audio has the very tricky characteristic of showing up and causing problems in practice only during A-to-D and D-to-A conversions.

Note that this is not general: in most of the other cases (especially very high speed communication) jitter must be kept under control (e.g. with the well known "eye pattern") because it can directly cause transmission errors in the digital domain too. The sampling and transmission rates required for audio are however so low that the problem is in practice not existing. Even data stored on a copied CD are, apart macroscopic cases, perfectly identical from a digital standpoint to the original (and nevertheless, the two can and do sound differently...).

Back to the audio case. Now, regarding A/D conversion, the user that buys a CD cannot do much if the original data have been recorded with some jitter: the best is to throw the CD in the waste (glorious end of which many older CDs are in any case highly worthy for tone balance problems...).

On the other end, during D/A conversion, instead, in order to reduce jitter to a minimum we just need to make the cleanest possible clock available.

The problem is easily and happily solved by hi class CD players builders by using very expensive clocks in the players, and just leaving the less fortunate people to live with it....

Note however that inside an integrated CD Player no S/PDIF interface to transmit the information from a chip to another: a whole bunch of more or less similar multi wire proprietary interfaces were developed, and no standard really took the lead, even because the I2S standard, one of the best available, was patented by Philips and only recently has become public domain.

Fast forward to: [Part 1.2] | [Part 1.3] | [Part 1.4] | [Part 1.5]