Part 4 – Clock Synchronisation
There is a problem posed when multiple digital audio devices, each with their own internal clocks, need to work together. Take the example of feeding a CD transport into a DAC. The DAC has a buffer – a section of temporary memory which stores the audio samples it receives from the CD transport. The transport’s clock dictates when a sample is sent out to the DAC, and the DAC’s clock dictates when the sample is used and converted to an analogue voltage.
In an ideal world, the clocks in the DAC and transport would be running at the exact same rate with no time variations. In reality, however, there will be variations in the clocks on average (potentially caused by the intrinsic jitter factors discussed earlier). This poses a problem somewhat different to jitter.
If the clocks are running at different rates, on average, over a long period of time, and are left to their own devices with no method of synchronising the two, there will come a point where either the buffer in the DAC has used all of the available samples from the transport, because the transport is sending the samples too slowly / the DAC is using them too quickly, or the buffer overflows because the transport is sending samples too quickly / the DAC is using them too slowly. This will result in the audio dropping out temporarily, as the DAC must drop everything and relock to the audio signal to get audio samples flowing properly again.
There are two main ways to address this issue. Firstly, there are pieces of timing information embedded within the digital audio signal that the transport gives out in S/PDIF or AES format. The DAC can look at this timing information and adjust the speed of its own clock to match. This means the clocks of the source device and DAC will now be running at the same rate, so dropouts will no longer occur.
The second method that can be employed is to lock both the source and DAC to a Master Clock. A Master Clock is a unit which sits external to all other units in a system and provides a clock signal, referred to as Word Clock, to the rest of the system. The internal clocks of all other units within the system can then be locked to this signal, meaning that on average, they are running at the same rate as the Master Clock. This means that at no point should the DAC suffer from dropouts or re-locks due to the buffer under or overflowing, as on average, the samples are being sent from the source device at the same rate as they are being consumed by the DAC.
The common factor between these two methods is that they both require a method of synchronising an incoming signal with the product’s internal clock, by way of a PLL. There a number of DACS in the high-end market which do not have the ability to match their clock domain to that of an incoming source, as the oscillator(s) run at a fixed frequency. This means that the unit will drop or repeat samples every now and again (definitely not desirable behaviour) and will have variable latency, so cannot be used for video because of the resulting lipsync drifts.
As an aside, it is worth noting that the use of a Master Clock in a dCS system does not replace the internal clock inside of the DAC. It simply acts as a stable reference for the DAC to lock itself to, and allows for DAC and source to be properly synchronised without issues such as intersymbol interference causing jitter within the audio data. The DAC’s internal clock still dictates when samples are converted, it simply adjusts its frequency over time to match that of the Master Clock. This means the DAC still benefits from having a high-quality clock close to the DAC circuitry. The clock directly controlling the audio is still part of a tightly controlled environment, while also being in sync with the rest of the system.
Phase Locked Loops (PLL)
A Phase Locked Loop, or PLL, is a circuit that works to match the frequency of an incoming signal with that of an outgoing signal. They are often used to synchronise a DAC’s internal clock to that of an incoming signal, such as SPDIF from a CD transport. A ‘phase detector’ in the PLL attempts to match the phase of the incoming SPDIF signal with that of the DAC’s internal clock. Its aim is to get the phase error as low as possible, ensuring that over time, the two clocks run at on average the same rate, and the DAC’s buffer never under or overflows.
The most common place to see a PLL in an audio product is within an ‘off-the-shelf’ SPDIF receiver chip. This chip will be utilised on the SPDIF input of a product, typically combining an SPDIF to I2S block together with a PLL. Using a third-party solution such as this can give rise to some issues. With such a chip, it can be very difficult to separate out the functions of signal conversion and clock domain matching. This becomes problematic when attempting to use a Word Clock signal as the clock master for the DAC. What’s more, if the performance of the chip isn’t up to scratch, then it is impossible to change it. AES clock extraction is a good example. This is actually quite difficult to do well; because of the structure of illegal codes within the signal, it is easy to induce jitter from the channel block marker that occurs every 192 samples (the structure of SPDIF/AES is beyond the scope of this post but in essence, the signal deliberately breaks the ‘rules’ by having periods of 3 0s or 1s in a row for various reasons, including to lock the PLL to).
At dCS, we’ve taken a different approach. dCS DACs still use a PLL, but it is a hybrid design, developed entirely in-house. Part of the PLL is digital, by way of DSP inside the product’s FPGA, and part of it is analogue. This lends an enormous amount of flexibility, and a much higher level of performance. Additionally, it is completely independent from the input source. We are also able to carry out functions like dramatically altering the bandwidth of the PLL. This allows the DAC to lock very quickly to a source, thanks to a wide bandwidth on the PLL. The bandwidth can then be tightened over time to reduce jitter.
This approach ensures that, within a dCS product, the clock and data paths remain independent. There is a part of the product’s FPGA which works solely to extract the clock embedded in, for example, the incoming AES signal (again, this is done using a bespoke design, rather than an off-the-shelf chip); another part which works to retrieve the audio, another for routing it, then processing it, and so on.
This gives us a tremendous amount of flexibility in terms of how we handle, for example, Dual AES: we can run the signal, have a separate Master Clock input, have the DAC act as the Master Clock for the whole audio system, tolerate different lengths of cables in Dual AES, and deal with phase offset between clock and audio, and all of this can be done without adding latency to the audio, meaning it can still properly integrate with video. We are also able to hide commands embedded in the non-audio bits of AES, which allows us to have, say, the Vivaldi DAC (a non-network equipped product) controlled by the dCS Mosaic Control app.
This diagram shows a simplified example of how a digital source (a Rossini Transport), a DAC (the Bartók Headphone DAC) and a master clock (the Rossini Clock) work together. The overall performance of the system is reliant on each of these stages performing correctly – each oscillator, PLL and output stage needs to operate at a high level to achieve optimum performance.
Clock Dither
The setting for Dither can be found on the dCS Rossini and Vivaldi Clocks. Dither is commonly found in digital audio, where it is used to expose dynamic resolution below that of the least significant bit. In the aforementioned Clocks however, the dither is applied to the time domain instead of the amplitude domain.
PLLs exhibit what is known as a ‘dead band’ in their phase detectors. When the input and output frequencies are close to being synchronised, they lose sensitivity. The PLL then drifts until the difference in frequency is large enough to cause the phase detector to once again become active and drive the PLL back towards being synchronised.
This is where the dither comes in: Perhaps counter-intuitively, if very small, random variations in the timing of the clock signal edge are applied when the phase error is very low, it gives the PLL something to latch on to and correct (as it pushes the phase error slightly back into the area where the phase detector can correct well). The dither is then filtered out in the PLL before it outputs the final clock signal. In practical listening this is a good trade-off and actually improves system performance. In essence, the dither setting on the Rossini Clock keeps the Bartók DAC’s clock very accurate even when the PLL is working in a less sensitive, low phase error area.