Its all in the DAC?

Murphthelab, it's interesting what you're saying, could you give some more detailed explanation? Especially what happening when you have an external DAC, which usually doesn't have a dedicated clock sync. line from a transport.

It would seem to me that a DAC has two choices:

1) Use a PLL and a divider to get the DAC clocking signal from the incoming digital datastream.

2) Buffer the incoming data into memory and clock it out to the DACs using its own internal clock that is not related to that of the transport. A large buffer would be required for this to ensure that it never runs empty if there is a slight offset between the clocks in the transport and the DAC.

In situation 1, which is the majority of DACs, the quality of the transport clock could have a profound effect on the sound quality produced by the DAC. In situation 2 I would expect the transport to have a much lesser effect on the sound quality, unless it was so lousy as to cause the DAC to receive bit errors.

The key is that to most DACs the SPDIF or AES signals are much more than 1s and 0s ... they are really an analog signal that must be sampled (to recover the data) and tracked (to recover the timing). The quality of this signal is rarely so poor as to cause bit errors, but can be poor enough to ruin the clock that drives the DAC.

Seandtaylor99 is right on the mark. In category 2, the Genesis Digital Lens is an example procuct (which I use). In this specific example, the box has some intelligence and measures the average difference between the transport clock and the Genesis clock (temperature controlled crystal). This way it can set the necessary buffering level without undo buffer delay.

I think for optimal redbook reproduction the best is to separate. There are good cheap "jitter boxes" like Monarchy Audio's DIP and DIP upsampler(wich I own) that can transform your CDP into an HiEnd transport.