Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Another D/A-question (Read 3508 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Another D/A-question

According to Pohlmann in his Principles of Digital Audio,
the process of going from digital storage medium to analog waveform is (if I've understood it correctly) like this:

The signal is stored as data on a digital medium, in a coded form (like EFM or MFM).

From there, the clockinformation in the bitstream is identified. In most cases, the signal contains time errors, "jitter". This can however be corrected by a PLL (phaselocked loop) and by data buffers.

From the storage medium, the code is sent to be recoded into a code that the rest of the signal chain can work with (usually NRZ, "non-return to zero"-code).

Audio and correction data are separated. The correction data is used to correct the errors bound to arise when data density is very high (the frequency and size of the errors vary however).
If that's not possible, the system tries to conceal the error. In it's easiest form, it works by keeping the amplitude of the last correct sample. In more advanced cases, a "bridge" is established between two correct samples.

The bitstream then enters the D/A-converter, which in a multibit delta sigma case oversamples the data and recuces the bitstream to only a couple of bits. Here, the data has taken on a pulse width modulation or pulse density modulation-form.
The bitstream then goes into a switched capacitor network, where an analogue waveform is created.



It all looks good to me, and I sure hope it is, too =)

But on to the question: where is the clock syncing up the data? In the DAC?

Another D/A-question

Reply #1 –
I just know the basics about it, so my answer may be inaccurate, but

In a standalone CD player, the data is clocked in the EFM decoder (it follows the path CD -> NRZ -> EFM -> CIRC -> DAC).
There is a buffer there that allows for servo mechanism to adjust the CD rotation speed.
The CIRC decoding and the DAC work in synchronisation with the clock, and the CD speed is slightly adjusted so that the buffer that feeds the EFM/CIRC part is always half full.

If the CD player feeds an external DAC with an S/PDIF cable, like an external receiver, then the DAC slaves its clock to the incoming data stream. This stream has an inaccurate clock (=jittery clock) because of the cable, but the DAC can correct most of this jitter. It has a PLL circuitry that rebuilds a stable signal whose rate is similar, so that the DAC clock remains slaved to the CD Player clock. But if the CD player clock drifts slowly, then the DAC clock is forced to follow it in order not to loose the stream. It cannot act on the speed of the CD and maintain its own clock (the receiver has no control on the CD Player). That's why we say that its clock is "slaved" to the digital input.

Another D/A-question

Reply #2 –
Quote from: status_brun on
But on to the question: where is the clock syncing up the data? In the DAC?

The clock is typically a low-jitter high-speed oscillator that feeds both the sigma-delta DAC and player demod/decoder. The buffer between the EFM code demodulator and the CIRC decoder is what queues motor speed control to maintain constant linear velocity.

For more info, this thread is invaluable...

http://www.hydrogenaudio.org/forums/index....showtopic=11909

Edit: Where no player is involved, the same high-speed low-jitter clock source is the typical case. The clock feeds the DAC, and the DAC masters a synchronous serial data interface (ie. supplies clock and frame sync, receives data) with the data source.