CD Transports: Data Drops Etc...

Ghost - Thanks for the info!

Still, this seems like a standard async communication problem (particularly in the single-box players) which has been solved in the computer data communications world. I think the serial rate on SPDIF is 2 mhz or 4 mhz.

If the dac is viewed as an async receiver (which I don't know if that's a valid view) then it seems existing engineering is available to get it right.

Still puzzled -
A

It's the framing error on a UART model that I have in mind for this data transfer too. Maybe that's the wrong mental model, and when I get the right mental model it'll be clearer to me. Certainly, one problem with digital audio playback is that these connections don't have redundancy built in (ie, no retry logic). However, I can connect two computers up via async ports (ie, UARTS) and write a simple program to send on one side, receive on the other, and report any chip-level errors, let it run for days and not see a single error, all without retry logic, etc. So, it still seems very solvable, at least to my level of understanding of the problem set.

I guess another way I think of it is this - what if somebody re-engineered the concept of a CD transport / DAC combination such that the transport didn't attempt to play it back real-time, but rather read the CD "in" and reliably loaded it into memory on the DAC. This would be akin to reading a computer CD into memory and, since you'd be re-engineering the interface, could base it on different technology. Then, the "CD" would play back from within the DAC's memory. I would think the whole issue of jitter would be moot with such a setup, and the whole notion of an expensive transport and expensive interconnects would be moot as well.-Kirk

Remember, that unlike an async serial data transfer between two uarts, the SPDIF signal contains both the data and clock streams intertwined. Unlike a uart, which knows a priori the operating baud rate, the SPDIF receiver must extract the clock from the incoming signal and then use this clock to derive the data stream from the signal.

Any distortions that round off the corners of the analog waveform making up the SPDIF signal cause the receiver to derive a jittery clock signal. In any digital logic, there is a transition zone between the voltages representing the logic states "1" and "0" that is neither state. A rounded off waveform spends more time in this transition zone, thus delaying the detection of logic transitions, thus affecting the derived clock signal.

This effect is not constant.

Improperly terminated coax (RCA plugs instead of BNC connectors, or bad transmitter/receiver design) will have reflections giving rise to standing waves which will cause distortion to the SPDIF signal.

Basic CD player design is still rooted 1983 technology. In those days memory and processor were expensive. I think that one could completely rethink the player design today, using current digital technology and its new price points.

Perhaps the CD drive (at 4x or better) could read ahead, and fill up a circular buffer. The data stream could then be clocked out of the buffer at a constant rate independently of the transport This scheme would even allow for retries of uncorrectable read errors, and would break the direct connection between data timing and transport timing. Of course we'd want to dump SPDIF as a connection mechanism...

I bet it would be easy to make using off-the shelf parts as well.