Get the most out of a transport + DAC couple - 3rd part

SPDIF Reclocking in practice

or

"Thinking badly you make a sin, but get it right"

(Giulio Andreotti, former Italian Prime Minister)

Product: SPDIF Reclocking for CD Player and Transports
Producer: DIY project, no component made available
Design: Giorgio Pozzoli - TNT Italy
Design date: Fall, 2001

Introduction

After the initial general article about the different connection methods between a Transport and a DAC unit, and the first practical one regarding clock substitution and relative benefits and limits, here is the second practical article of the series.

The topic is how to optimize the use of a very high quality clock in the transport or in a CD player used as transport, which is the most frequent case with low to medium class units, to achieve the best results not in terms of sound from the local converters but in terms of precision and cleanliness of the generated S/PDIF flow.

For a general discussion and explanation of terms please refer to the initial article of this series.

The solution

The idea is very simple: instead of wasting clock precision by loading it with all the original circuitry, the best clock is to be reserved exclusively for cleaning up as much as possible the S/PDIF output flow, while a "rough copy" of the clock is used to achive a perfect sinchronism in the rest of the unit, without any special care for jitter and precision.

In facts, an advantage of synchronous digital systems, like our transport unit, versus the asynchronous ones is that the digital signal level cannot change at any time, but only in specific moments. So, if you have a signal affected by jitter, and you have a jitter-free clock which the signal is sinchronous to, it is possible to build a slightly delayed but jitter-free copy of the original signal just by reclocking it, that is, resampling it with the jitter-free clock.

The application is rather simple too. In practice, there are two issue to address.

First, you need a very high quality, jitter-free clock, and have sinchronize all the transport with this clock. If your unit is medium to high quality, it is probable that the clock is already at an accetable level. Anything in the consumer area has for sure a low quality clock.

In this case, the best solution is the most radical: eliminate the clock generation system (normally just a quartz with a couple of capacitors and an inverter gate, and install one of the many super clocks available on the market (e.g. LC Audio, NET,...) in place of the standard clock.

Just to give a complete picture, another theoretical solution could also be to use a very high quality VXO (voltage-controlled crystal oscillator, and lock it on the original clock using a PLL (phase locked loop) technique.

This solution is in any case far more complex then the previous one, and therefore we will disregard it, even though the terms of the problem could really make a good solution possible (the problem with PLLs is that if you need to achieve a very high stability, you must cope with very long locking times and a narrow locking band, but in this case these might not be serious problems).

Second issue, you obviously need a reclocking circuit. The circuit is very simple, but the installation can present some problem.

The problem is that you need to identify on the board the S/PDIF data flow at logical (CMOS or TTL, very roughly 0/+5V) level.

This can be not easy at all, unless you have the schematic, and also in this case it might be simply not possible, because if the unit has not been designed for a digital out, then it can be also possible that the S-PDIF signal is not available at all on the board, and even in case the unit has a digital out, than the S/PDIF data might be available only at S/PDIF electrical level (the one used in the coaxial connections, 0.5-1V), which is definitely too low for our purposes.

In facts, some transport controllers output directly an S/PDIF electrical signal (e.g. Philps CD-PRO and CD-PRO2) while others output only a 3 line bus (like Philips' I2S). In both cases the reclocking circuit becomes somehow more complicated.

In the first case, you should use a S/PDIF line receiver (for example a DS34C86: a complete digital audio receiver like the CS8414 is not required, even though for example the 8414 can also be used in this way in mode 13) to receive the flow and elevate the data level to CMOS/TTL, before reclocking it; in the second, you need a complete digital audio transmitter (like the CS8406, for example), to transform the 3-line bus data into the S/PDIF flow.

The simplest case to address, and the one we will describe in detail, is when an optical digital output is already available.

In this case the required signal is present on one of the connection pins of the optical interface (TOTX). The other ones are normally connected to +5V or ground, and therefore the hot (that is the one with the signa) can be easily detected by measuring the resistance between ground and +5V and each pin using a normal tester as ohmmeter.

In case of doubt, anyway, you can also refer to an interesting document by Tomi Engdhal available on the internet (originally at http://www.hut.fi/Misc/Electronics/docs/audio/spdif.html), that contains really a lot of information regarding SPDIF and digital audio interfaces.

Now we have the clock, the input signal, the reclocking unit. We need to bring the reclocked data to the standard S/PDIF level and take it to the output connector.

If the transport already has a digital out, one is strongly tempted to use the original circuits and connector. This is however not a good idea, especially where the cost reduction have been heavier.

Consider that most people consider the SPDIF output just a nice to have, that no one ever tests the digital output while buying a CD player, and that most of the owners will never use it at all: no one can be surprised if regarding digital interfaces anything more than basic workability is considered pure cost by the manufacturers of a low cost CD player.

The simplest solution, and the one that allows to get the best results, at this point, is to build a completely new electrical output.

A further important element must be taken into account.

No high quality circuit can give his best if its power supply is dirty, noisy, not perfectly stable.

Therefore a clean power supply, independent as far as possible from the general one of the transport unit, is required to achieve the best results.

Further care must be taken to make the power supply of the clock and of the reclocking as much independent and uncorrelated as possible.

For this reason local filtering and regulation should better be present.

The design

In the following is detaild a possible implementation. The design was tested in a Pioneer PD-S505 CD player.

The clock and reclocking units are separate. This is due essentially to the need I have to be able to compare different clocks: there is no reason for you not to put both circuits in the same board provided you keep the clock a little apart in order to avoid or at least reduce disturbs propagation.

For the same reason, use in any case a ground plane: it is a very powerful method for reducing any sort of bad mtual effects between the different components.

For the clock, you can choose any special low jitter clock on the market. If you already have one, you can just use it. If it really is such an high quality, it should already have a local regulation and filtering in place. If it has not, add one.

Unless the transport unit is already a high quality one, it is probably not the case of spending a huge amount of money to have the absolute best: we will see later on why. Personally, I used both commercial audio clocks, and an industry standard monolithic low jitter clock. The results were definitely very similar.

In case local regulation and filtering are not present, is definitely better to add them: this is a good old practice to minimize cross effects between the clock and the reclocking unit.

The schematic (which refers to the industry standard monolithic clock implementation) presents also this circuit in detail. Note that you will have to review the values of R101 and possibly also of R13 and 104 because of the potentially different power supply current required by the clock. Please refer to the TL431 data sheets for details.

The clock must be placed as near as possible to the reclocking unit, which should be as near as possible to the output connector; the distance from the original clock position and the

I missed a very good point, however, in the design. It would have been definitely better to add a buffer (a 74HC04, for example), to the clock branch that drives the original transport or CD circuit, in order to reduce and stabilize the load of the clock. As a matter of fact, the clock circuit was designed first, just to substitute the standard clock inthe CD player. So this arrangemenet was at least not necessary, if not definitely bad.

In anycase, DO NOT use the spare inverters available in U105 for this clock buffering. It is for sure better to add another hex inverter for the sake of clock precision and cleanness. The power supply too should come from the clock branchand adequate de-coupling is required.

The reclocking and line drive unit is rather straightforward. The reclocking is siply obtained with a D type flip flop, which samples the input value on the rising edge of the clock, and keeps the output stable to this value up to the next clock rising edge. That's really all.

The output driver has been inspired by (should better say taken from..) the interesting document by Tomi Engdhal named before and originally published by Elektor. It seems to be one of the best and sound approaches, with enough power to drive the 75ohm line and enough speed to keep the signal edges as fast as possible, which helps a lot in reducing jitter.

The output transformer is just home made. I used a ferrite toroid from RS Components as a core, part number 212-0831, and just wound up both primary and secondary coils with enamelled copper solid core wire (the one used for normal power transformers secondary coils). Unfortunately the original ferrite toroid is no longer available; try finding something similar of small dimensions.

The primary winding has 15 turns, ad the secondary 3. Initially I used 5 turns on the primary, which provided a far higher output level than the standard one; this in my view should have made the transitions even more vertical and less affected by noise and jitter, but further measuring proved instead that a S/PDIF level higher then the standard one instead caused more data coreelated jitter. So you should better stick to the figures above.

The installation

First of all the original clock must be eliminated. Please refer to the instruction of your clock (or the ones of the LClock, that are very complete and detailed and are available for a number of different units) to find the clock components, and eliminate them.

Next, you should better install a new SPDIF connector. The connector must be insulated from the cabinet. Use te specific types.

The connector can be either an RCA or a BNC. I prefer the BNC, because is available with a precise 75ohm impedance, but I am not completely sure this can really make big differences... especially if the wire is not exacly 75ohm too...

We have now to prepare the wiring. As said, first priority is to keep the wiring between the clock and the reclocking unit, and between this last and the SPDIF output connector, as short as possible, no longer than very few centimeters. Then lower priorities are to keep short the connections between the new boards and the new power supply, and from the clock board to the original clock position.

For all the connection, a solid core twisted couple, taken for example from a UTP Cat.5 network wire, can be used.

Avoid creating multiple ground paths between the different boards and units. Follow exactly the schematic. There are six connections to be taken care of.

First, always with an eye to the clock installation instructions, connect the two MCK and MCK_GND wires respectively to the hot and cold original clock soldering points. Be careful in connecting each wire to the corresponding spot. You should better use a twisted couple.

Second, the SPDIF signal must be extracted from the original board with a single wire; you can use here too a twisted couple, but you must avoid connecting the cold wire to the original board (you can connect it to the reclocking board only).

Third, same as above for the MCK connection from the clock board to the reclockng board: use a very very short single wire, or a twisted couple with the cold wire connected on one side only.

Fourth and fifth, you need to connect the new power supply unit to the clock and reclocking unit pins; use a twisted couple here too.

Finally, you need to connect the new power supply unit to the transport input mains connector or soldering points. Use a wire that can cope with the high voltage involved: do NOT use cat.5 wires here!!! Keep the wire as far as possibe from digital and audio circuits to prevent mains noise to be picked up.

At this point you have just to switch the unit on, and hope everythings works fine...

The Sound

Issues

The S/PDIF flow is based on the biphase mark encoding, with violations inserted to detect the subframe starting point. Unfortunately, this code has a well known flaw.

It is possible to prove mathematically that the clock that can be retrieved from such a flow is in any case affected by jitter correlated to the data. That is, it is not true that the data and the clock can both flow independently on a spdif connection...

If this is true (and there are papers from AES about this) then it is clear that there are problems at the horizon, isn't it? But for sure the SPDIF receivers will take care of the problem, you are thinking.

In facts, they take any possible precaution to avoid extracting a clock affected by data correlated jitter by using the most sophisticated strategies in choosing to lock onto the points that are the least affected by intersimbol interference.

For example in the recent CS8416 Digital Audio Interface Receiver "the PLL has been designed to only use the preambles of the bi-phase encoded stream to provide lock update information to the PLL", according to the data sheet: "This results in the PLL being immune to data dependent jitter effects because the preambles do not vary with data" (which is not completely exact, by the way...).

Similar concepts were expressed also in the CS8412, 8414 etc. receivers datasheets. Texas Instrument's DIR1703 makes use of a "Sampling period adaptive controlled tracking system (SpAct)", which "is a newly developed clock recover architecture, giving very low jitter clock from S/PDIF data input".

But if you now have a look to the chips specifications, you just find out that all of these units do not attenuate significantly any jitter below 10KHz at all. Some do not attenuate jitter up to 40KHz.

Hance there are very good possibilities that some jitter comes in through the PLL. And there is also no evidence, as far as I know, that low frequency jitter does not have any effect in digital audio reproduction. The question is simply solved in some data sheets with the general assertion that most jitter is at high frequencies, and so the receivers are reducing it consistently. In a word, all the DIRs are doing a great work, with jitter. According to DIRs producers, at least.

Is this true?

What we would need is a way to measure jitter.

Unfortunatel jitter is a very elusive element, and its measure requires very specific instrumentation. Direct measure is possible, but requires scopes with discrimination capability in the picoseconds range, which are very expensive. An alternate solution to have an indirect measure of jitter is based on the fact that a spectrum analysis of a pure sinusoidal signal affected by jitter shows symmetrical side bands at both sides of the fundamental frequency. So a very precise fft extended up to 11289khz could be usefule, so that we can measure side bands caused by jitter on the MCK regenerated by a DIR. We just need some half a millon dollar analyzer, and it's done...

Another possible, lower cost solution could be to mix the output of the clock under test with a very stable reference clock, using in some extent the etherodine effect (like in radio receivers) to translate the MCK frequency to a far lower band, and analyze it with far lower cost instrumentation.

I have no access to such a sophisticated instrumentation, and did not want to set up a mixer, but I tried to see it was possible to retrieve any kind of usable information, using my poor instrumentation, with very scarce hope of success, I must say.

I have a Pico ADC 200 digital instrument, that works as a digital oscilloscope and fft spectrum analyzer. For the specific usage I was addressing, it has a big disadvantage, has only 8 bits, so that the highest achievable dynamic with averaging techniques is around 64 dB. It has a sampling frequency of up to 20MS per second, which makes it not very good for digital interfaces, a limited buffer size, that reduces a lot the FFT precision and finally one more defect: there is no antialias filter, the input range goes up to 10MHz at any sampling rate.

Is anyway rather precise, in a word is a real even though low cost measurement instrument, not a toy.

Looking at an FFT with the maximum frequency range, 10MHz, I clearly noticed the aliasing effects, and after a while I realized that there was perhaps a chance of using these effects for our purposes. In facts, aliasing works in a way that is quite similar to etherodine...

So if you take an ADC200, set the fft range to 156K, the horizontal zoom to 10x, the number of fft points to 4096 (the maximum) and the sensitivity to 50mV (the minimum), and connect it to the MCK pin of the 8412, what you can expect to see?

Well, I was amazed too, but if you look around 41KHz, you can see a reasonably good image of the 11.289MHz clock. The frequency is transferred due to aliasing, so without any compression on the frequency range. The signal is terribly clipped, there are other alias images disturbing the picture, the clipping at least reinforces creates a number of fake images due to the harmonics (which are in any case present, because it is a square waveform), but....

The spectra you get with no signal (all zeroes, when it is in pause, or stopped) from the transport, and when some music is played, is definitely different. With any music played (remember that we are measuring a clock, which should be completely independent from the musical program!) the clock noise floor is at least 3 dB higher than with the transport stopped or paused.

This might be just due to the fact that the 8412 might switch the clock to an "internal mode" if there is no significant signal at the input. But if you perform the same test with a CD playing digital silence, you get the same spectrum both when the cd is playing ad when it is in pause. If you switch the CD Player off, the PLL start moving around for a frequency to lock to, and the situation shown by the spectrum analyzer is completely different.

You can also have further evidence, if you need it, because if you play a pure sinusoid at different frequencies, then different, symmetrical, spikes appear in the spectrum around the central fequency.

Obviously all these tests are consistent and repeteable. So it seems that in the end the clock is really correlated to the signal.

By the way, the noise floor of the 8412 MCK is much higher than the one of any good quality clock (including a misfunctioning one...) I measured.

But... the digital interconnects?

I did not say anything about digital interconnects. There s a lot of hipe about theyr effects and importance. Is this real, and if it is real, is it measurable?

Well, the measures I made proof that the wire can make very big differences in terms of MCK jitter.

Their effect seems again larger than the difference you can expect between two high quality clocks; this, if does not explains completely, at least gives a way to measure the effects of nad give some kind of objective evauation of different interconnects.

As a minimum, gives objective evidence of the fact they can affect the sound quality in such an evident way as reportd by golden ears.

There is one further element to discuss about interconnects: the fact an interconnect seems to work better than another with a specific transport and DAC, cannot give an absolute measure of the interconnect quality. Have a look at the following picture: the two A and B interconnects are the same as in the picture above (yes, I am sure... I checked everyting at least 3 times...).

So once again the general idea that the quality expressed by a digital interconnect depends essentially on the impedance matching of the whole channel, including both terminations, seems perfectly confirmed.

Conclusions

Based on the measures shown above, the minimum jitter that can be achieved in a separate DAC seems to be primarily limited not by the clock quality, but by intersymbol interference of biphase mark code, by the interconnect and by the receiver quality. Currenty, the existing receivers seem all, if not rather poor... well, simply not good enough!

So this article, and all the work done around it is completely wasted... or not?

I do not believe so at all. The tests done proof that with the limited cost of a good quality clock and with a simple reclocking circuit you can bring a low cost transport or CD player to provide a digital output that strictly approaches the best SPDIF transmission interface available today.

In any case further improvements of clock quality seem to be scarcely effective, as the communication channel and the characteristics of the PLL at the receiver side contribute in a very consistent way to the jitter in the DAC system, masking out most of what can be gained with a better clock.

The marginal improvement that can be achieved is therefore something that can be of interest only for very high end estimators, with a lot of money.

It is instead definitely confirmed that the digital interconnect must be carefully selected, as their effect on clock is definitely relevant.

In any case, all tests confirm that the line followed by the most avanced digital audio equipment companies, trying to improve the interface performances is justified.

The usage of proprietary interfaces with multiple connection in order to transmit clock and data on separate wires, as already often happens in professional environments, seems reasonable, even though this solution cannot be fully leveraged by standard equipment, and for sure is not the only one.