Doesn't DAC Do Heavy Lifting vs. Transport?

Bigbucks - I assume your question about using a buffer is for me. The point I was trying to make is that the amount of jitter in a transport is an important consideration for achieving good sound. This was an attempt to address the OP's question, "Does the transport impart its own influence on the sound?" I only mentioned the reclocker as an illustration of how jitter was audible in my system. But you are correct in pointing out that, when a reclocker is used, the jitter characteristics of the transport are less important, or perhaps irrelevant, depending upon the method of reclocking. Similarly, if the DAC reclocks the incoming signal, the jitter characteristics of the transport are less important, or perhaps irrelevant, depending on the method of reclocking.

I guess that I always have assumed (there it is) that an external DAC doesn't ever rely on the transport for data timing. Instead, it empties its buffer at the right time intervals according to its own clock. Therefore, the only jitter is the DAC's jitter and the transport therefore must be totally irrelevant. Your experience means what? That some DACs don't use their own clock and instead rely on the transport's clock?

I just don't understand (unfortunately).

I have owned 5 or 6 (probably more) dacs and thought each had a unique sound. In my experience the transport, which was the digital out from a cdp or dvd player, was irrelevant. At least I could hear no difference when subbing in a different transport.
I'll take it one step further and say it is the analogue output section of the dac that is most important. What I mean is the number crunching done in the dac to provide the analogue signal is not as important as how the analogue signal is delivered. Of course YMMV.

Bigbucks5: I guess that I always have assumed (there it is) that an external DAC doesn't ever rely on the transport for data timing. Instead, it empties its buffer at the right time intervals according to its own clock. Therefore, the only jitter is the DAC's jitter and the transport therefore must be totally irrelevant. Your experience means what? That some DACs don't use their own clock and instead rely on the transport's clock?

Your questions are excellent, Bigbucks, as are the op's. The answer is that, yes, run-of-the-mill transport + dac combinations rely on the transport's clock. And due to the fact that a conventional SPDIF or AES/EBU interface does not provide a means for slaving the timing of the transport to the timing of the dac, avoiding reliance on the transport's clock creates considerable complication and added expense.

What you are envisioning is a FIFO (First-In, First-Out) buffer in the dac component, with data being clocked into the buffer synchronously to the transport's clock (as extracted from the SPDIF or AES/EBU data stream), and data being clocked out of the buffer by a completely independent (asynchronous) clock, generated internally within the dac component.

That approach has been used in a number of high end dac's, with some success. However, with no synchronization between the dac clock and the transport clock, and if the buffer size is not very large, expectable tolerances in the accuracies of those two clocks WILL cause the buffer to either empty or overflow, during the hour or so of music that a cd may contain.

Avoiding that possibility requires either a large buffer (at least several seconds long, I believe), which increases cost and also creates a corresponding delay in the start of playback, and/or sophisticated means of periodically re-synchronizing to eliminate accumulated timing drift between clocks, without affecting the music.

A one-box player avoids all of those difficulties because although data retrieval from the disk and clocking of the dac chip occur at completely different rates, and a buffer memory is incorporated between the transport section and the dac section, all of the clocks are ultimately derived from a single internal clock generator, so there is no long-term drift between them.

The fundamental problem with two-box approaches is that the SPDIF and AES/EBU interfaces provide for clock transmission in only one direction, from transport to dac. And the fact that clock and data are combined into a single signal, requiring the clock to be extracted from that signal in the dac component, only makes matters worse in terms of providing a jitter-free clock to the dac chip.

Re asynchronous sample rate converters, and other approaches that have been used to work around these fundamental limitations, fwiw here are some words from Charles Hansen of Ayre, in this excellent white paper:

Over the years many schemes have been implemented by various manufacturers in attempts to improve the jitter performance of the S/PDIF connection, including dual PLL’s, VCXO’s (Voltage-Controlled Crystal Oscillators), frequency synthesizers, FIFO (First-In, First-Out) buffers for the audio data, external re-clocking (”jitter reduction”) devices, and so forth. While all of these methods are able to reduce the jitter levels, they cannot eliminate the jitter that is inherently added by the S/PDIF connection. Another approach to reduce jitter that has become increasingly popular in recent years is to use an ASRC (Asynchronous Sample Rate Converter) chip. The idea is that the original audio data is replaced with newly calculated data that represents what the audio data would have been if the incoming signal had most of the jitter filtered out. The technical theory behind this method is sound, as demonstrated by the measured performance, which is generally quite good. However the audible performance of these devices is controversial, and Ayre has avoided this approach as it completely discards the original audio data.

On another note, happy 2010 to all!

-- Al