Why DAC64 is transport/cable dependent

I was answering a thread on the same topic in another forum (Portuguese one) when I light bulb went on in my head and I figured something out

I've always argued in the past that, with its 4 second buffer, the DAC64 should be independent of the transport and/or digital cable used, afterall, it's reading the data into the buffer which is a "digital to digital" transfer (like a CD -> CD copy) which are immune to jitter.

I've also "backed up" my hypothesis in the past by suggesting you take the 4 second buffer to it's logical (but admittedly silly) limit of 80 minutes If you had an 80 minute buffer then you could "copy" the CD to the buffer, turn the transport off and then away you go. Well, yes, in that case the DAC64 really would be transport and cable independent but the difference between 4s and 80mins is a significant one, not just a question of the time involved.

Because the DAC64 is always connected to a transport and has to react in real time (ok, with a 4s delay) to what tracks the transport is playing etc and is not a load up a CD, one shot device, it has to stay synchronized with the clock in the transport and therefore it depends on the clock signal being sent by the transport and over the digital cable and therefore it is not immune to jitter. The RAM buffer helps a lot for sure, but over time, the DAC64 has to stay synched with the transport.

There's an easy way to test this theory (I just did it) :
Start playing a CD through the DAC64 and then switch off the transport (don't just press stop). Even though the buffer has 4s of music left in it the music will stop immediately. This is because the DAC64 has lost the clock signal from the transport, without which it can't do anything.

If you merely press stop or eject, you get the "party piece" 4 seconds of music whilst you're already putting the CD back in its case trick, but that's because as long as the transport is switched on, it's sending a clock signal to the DAC, so the DAC can continue.

Michael.

 

If the buffer isn't just for party piece purposes then it shouldn't be synchronised with the clock derived from the transport. The replay clock needs to be slaved to the transport so the buffer doesn't over or under flow, but the sample by sample jitter can be independent.

Of course there's no guarantee that the DAC64 clock is less jittery than the transport....

There was a fashion some time ago for proprietary synchronisation connections between transport and DAC. I think I prefer that both are put in the same box, transports aren't too difficult or expensive nowadays.

Paul

 

You're right Paul - it's only the replay clock that needs to be slaved to the transport, but that's why the DAC64 is transport dependent and digital cable dependent.

On the issue of having DAC and transport separate or in the same box, there are arguments for and against each solution.

Michael.

 

Mike, well I hate to say I told you So , as for single dual boxes, if performance isn't an issue, then one box is a no brainer, I aint going there tonite can be arsed to much typing and well an 861 is well a bit boring these days :SLEEP: WM

 

Yep - but you couldn't explain to me why Now I know though.

Doesn't stop the DAC64 from creating the best sound I've ever heard from redbook CD though

Michael.

 

I'm not the only one who thinks the DAC64 makes the best sound from redbook CD, money no object. However, these things are all subjective, which is why we have our little forum

Point is, I'm happy with it and that's all that matters :beer:

Michael.

 

I don't know how a DAC64 actually works but that seems unlikely.

Unless it uses a very stable low jitter clock for replay what is the point of the buffer? The frequency of that clock will have to be adjusted to keep the buffer full, but the rate of that adjustment should be very low and essentially inaudible, if it's happening over a 2 or more second window.

I suspect the good performance of the DAC64 is independent of the large buffer, but that the large buffer makes it easier to sell.

The connection between transport and DAC is one of the few places in audio where transmission line theory applies, where terms like 'characteristic impedance' actually have relevance. I think that many transport/digital cable variances are down to impedance mismatches and the reflections these cause blurring the clock edges.

Paul

 

Michael

Although your observations are certainly one explanation for the effect that you have observed, they do not make much sense if the buffer in the DAC64 has been designed to improve the audio performance rather than as a marketing tool. They also do not explain the vast difference in sound produced in the different buffer modes (4 sec, 2 sec, no buffer).

An alternative theory might be:

The DAC64 does fully slave to the transport clock in no buffer mode - essentially it works exactly like any normal DAC. In this case if the clock signal is interrupted there is no point in continuing to process as there is no information so the DAC switches off. Although in buffered mode, if my theory below is true, there is no need for the processing to stop the moment the digital signal is stopped, Chord decided that there was no benefit in having a different method of operation for each buffer mode (and saved some cost by just having the one detection circuit).

In the buffered modes synchronisation might occur in one of two ways: either there is none and the full available buffer is not used to allow for data overrun/underrun. I dont know if this is feasable as I don't know the range of variations in clock rates between CD players/transports - a 4 sec buffer would allow for a 0.0833% clock rate variation over 80 minutes of music without further readjustment. Or the clock rate of the incomming signal is measured during the filling of the buffer and the DAC clock rate adjusted only once at this time. Or maybe it is adjusted again at set intervals?

I cannot think of a way to independently test my theories.

I also have to say that I agree with Paul; that the DAC64, even in unbuffered mode, is a fine sounding DAC but I have observed such drastic improvements in tone and soundstage by using the buffer that I cannot believe that it has no effect and is simply a marketing ploy.

 

For my money, The DAC64 without the buffer is average at best. With the buffer, the performance improves noticeably, suggesting that Paul's rather predictable comments re marketing tools are, as usual wide of the mark.

How it works, heaven knows Two questions arise for me. One is that I was under the impresion that the clock signal is only embedded in an AES/EBU connection, not with SPDIF, so where's the reference in this case

Secondly, and more puzzling, I tried running two of them in my system a while back, both taking AES/EBU out of the TacT. And guess what, they would not run in sync to save your life So the only thing to deduce is that either the RAM buffer is slightly different in each unit, or they do not slave to the transport clock at all, and the internal clocks vary in their accuracy.

Still a fine DAC if you only need one and don't mind the delay

 

Interestingly, the Teac D70 uses a PLL circuit, a word bit clock and a far bigger ram buffer than DAC 64, with switchable upsample rates, only in the direct Mulitiples, all of which are switchable, however to me it sounded at it's best with the word bits clock activated, again syncronising the clock in the transport, form extracted word bits from the sync signal in the AES line. WM

 

I think WM, Paul Ranson and NOS have covered this collectively but to bring it all together:-

Its easy, if you know what a buffer means:

Again, this does not contradict a buffer...

The datastream is sent out by the transport continuously with no flow control from the DAC [ie error/re-try/start-stop messages]

The buffer has an input PLL circuit which latches onto the incoming data [so it can adjust for different data rates] If it doesn't capture a frequency [as Michaelab suggests because the box is off/not connected] then the DAC is aware that the PLL is not locked on and ignores anything in the buffer [as corrrupt/not needed]

The data is being fed into the buffer synchronised to the clock rate of the transport. If source jitter is relevant then it is lost when the bits are "frozen" in the memory cells [assuming no misreading].

The DAC starts decoding the buffer when it contains a certain level of data, perhaps 1/2 full. It ADJUSTS its own clock rate to maintain the buffer at around this level of fill so that it doesnt have to rely on the clock of the incoming data signal.

The clock of the DAC is therefore synchronised to the AVERAGE clock speed of the incoming - with a 4 sec integration window.

So 2 DACs in parallel are not in sync. They may also have slightly different buffer sizes for manufacturing reasons. Also the DAC clock might drift VERY slowly as it only has to react to the buffer filling speed

Jeez Merlin, I thought a physicist like yourself would have it all sussed...!

My quote of the week:

cheers all,

Graham C

 

Thanks Graham for that explanation Now it makes sense. Given that, it makes it hard to understand why the DAC64 is as sensitive to different digital cables as pretty much any other DAC. I doubt that even the worst cable or transport could introduce clock jitter so bad that it would seriously affect the average clock speed over a 4s integration window

Merlin - I'm shocked! How else do you think that a DAC and transport should sync up if the clock signal is not embedded in the connection (and there isn't a separate clock link of course)?

The embedding of the clock signal in SPDIF is the key reason why it's detractors say it is "flawed". The same goes for AES/EBU. In fact, the datastream sent via SPDIF and AES/EBU is, for all intents and purposes, identical.

Michael.

 

OK Graham, thanks for the explanation

So, please explain the following. I had two identical AES/EBU cables transmitting the data from one internal clock located in the Tact. These fed two DAC64's. The data being sent was identical but the sound kept going in and out of sync between the two dacs?

This does not happen with Dacs employing standard topology, neither does it happen with Tact digital Conversion. Basically, the only explanation, is that the Dac 64 is slowing down and speeding up, much like the pitch instability and speed drift in many turntables.

So we can therefore say that the analogue signal fails to stay in sync with the digital one. How does that translate to accuracy

So we get drift and varying sizes of buffers We don't get these issues with other Dacs, regardless of whether they use PLL at their inputs. Sorry but I don't see anything clever in that, in addition, using a very high precision off board clock with clock link inputs on transport and Dac will offer similar benefits, without the attendant failings.

OK Michael, sorry I am no expert here But could you explain why clock generators as used in studio applications, and indeed my own CDR, are able to extract a wordclock signal from an AES/EBU feed but not from SPDIF. They can however send Wordclock signal via SPDIF to a wordclock input on a suitable unit.

 

I'm no expert either merlin and I don't really know the answer to your question. At a guess it's because wordclock extraction etc. is something used mainly in the professional/studio environment where AES/EBU connections are the norm.

I said that the datastream in AES/EBU and SPDIF is "to all intents and purposed" identical, because I knew there was a very subtle difference but I couldn't remember what it was. Now I have "An Introduction to Digital Audio" by John Watkinson infront of me I can tell you the differences :

The subframe structure of the AES/EBU (and SPDIF) format is as follows:
- 4 bits of preamble
- 4 auxiliary bits
- 20 audio sample bits (which can be combined with the 4 auxiliary bits if 24 bit samples are being used)
- 4 status bits

The 4 status bits are:
- validity flag
- user data
- channel status
- parity bit

Now, to quote:

"In both professional (AES/EBU) and consumer (SPDIF) formats the sequence of channel-status bits over 192 subframes builds up a 24-byte channel-status block. However, the contents of the channel status data are completely different between the two applications."

It then goes on to explain what information each of the 24 channel status bytes contains (in the professional application) but I'm not going to reproduce that here However, it's all stuff that would be very useful in a professional environment and not very in the consumer one. The first bit of the first byte indicates whether the channel status block is in "consumer" or "professional" mode.

None of the "extra" information sent in AES/EBU in the channel status block would be particularly helpful in extracting the word clock though.

Michael.

 

It doesn't matter whether the switchable buffering affects performance, it is a fantastic sales tool. If the DAC sounds better with buffering at max then all the better.

I don't understand why such a large buffer is considered necessary, but I'm sure Chord have good reasons.

Paul

 

Paul, I don't think anyone has bought a DAC64 because it has a 4 second buffer. They've all bought one because it sounds sublime

The longer the buffer the more time over which the transport clock signal can be averaged and hence the more accurate it is likely to be. I believe Chord were tempted to use an even larger buffer but weighed that against the annoyance of the delay when using it so, if anything, the buffer (well, the delay it causes) is a bad thing as far as sales and marketing are concerned.

Michael.

 

Michael,

Have you terminated the Apogee cable, how does it sound...

 

It sounds very good. I'm using it in between my transport and the Monarchy upsampler. I'll do some tests with it comparing it to my balanced LAT cable just between transport and DAC. Of course I terminated it with Bullet Plugs

How much do I owe you btw, did JP decide how much it costs?

Michael.

 

Great value, those Apogee... :MILD:

Not yet, he will take his time, don't worry...