dCS Ring DAC - A Technical Explanation

Part 2 - Jitter (intrinsic)

There are two main kinds of jitter: intrinsic and interface. Intrinsic jitter refers to jitter which is produced inside of a product like a DAC, through effects like phase noise on the oscillator. Interface jitter refers to jitter which is picked up by the interface(s) used to transfer the audio and clock signals. This could come either as interference picked up by the cable itself, or through the cable essentially acting as a filter for certain frequencies, impacting the integrity of the square wave (the output of the clock circuitry) passing through it.

There are several varieties of quartz crystal oscillators, but Voltage Controlled Crystal Oscillators (VCXOs) and Oven Controlled Crystal Oscillators (OCXOs) are two of the most common in audio.

Voltage Controlled Oscillators, or VCOs, are also used in audio products, but these operate on a purely electronic basis, and do not use an electromechanical material such as quartz to generate signals.

Quartz oscillators tend to have better phase noise performance than VCOs, meaning the oscillator itself may be less prone to jitter. What this means in terms of overall clock design is that in a DAC with a quartz oscillator, the Phase Locked Loop, or PLL (the circuit which matches the frequency of the DAC’s clock to the clock of the incoming audio signal) can be biased towards rejecting interface jitter by means of a narrower PLL bandwidth.

This is possible as the quartz oscillator itself is less prone to phase noise and subsequently jitter. As such, if jitter should happen to be present on the interface, for example a jittery AES signal, this jitter will not be passed on to the DAC, as it will have come and gone before the PLL reacts to it. The DAC instead relies more on the oscillator for timing accuracy between individual samples which, in the case of a dCS product and its quartz crystal-based clock, is a very high level of accuracy.

The alternative to this would be to use a VCO as the oscillator. However, given the potentially poorer phase noise performance of a VCO compared to a quartz oscillator, the PLL within the product may need to be biased towards rejecting intrinsic jitter, as the oscillator itself would likely be more prone to phase noise, which can be achieved through using a wider bandwidth PLL. This means any interference or cable filtering effects will have a more direct impact on the sound which, in some use cases, may be undesirable.

If this is the case, you might be wondering why any product would use a VCO as a clock source. One benefit of using a VCO over a quartz oscillator is the possibility for the clock to have a greater ‘pull range’, meaning it can lock to a wider range of signals (for example, signals running consistently too fast or too slowly).

In our experience, in the context of a high-end digital audio playback system, the quality of a DAC’s clocking should not be permanently compromised to allow for a sub-optimal source to be connected and work properly. At dCS, we opt for using a quartz-based oscillator with a high level of accuracy and stability, allowing for a pull range of +/- 300 parts per million (PPM), as per AES specification.

These graphs show an exaggerated example of the effect of jitter on the square wave output by a clock circuit. As previously discussed, jitter has both impacted the transition times of the wave and the peak voltages the wave can reach. This has the effect of changing the point at which the system would perceive, for arguments sake, a 0 changing to a 1. Clock systems watch the ‘rising edge’ of the clock signal where the voltage increases, so the point on the rising edge where the amplitude goes above 0.5 has been marked on the graphs. The timing of this is regular in the first graph – the transition points on the rising edges fall on 2, 4 and 6 on the X axis respectively. When jitter is introduced, the transition points are shifted forwards or backwards depending on the nature of the jitter. It is not regular, it is random.

There are several factors that can cause phase noise (and, consequentially, jitter) on an oscillator, and these should all be taken into account when designing a clock system.

Physical Vibrations

As the basis of a quartz clock is its piezoelectric property (the physical movement of the crystal when a voltage is applied), any external physical vibrations can cause inaccuracy in the clock. The extraneous movement does not need to be vigorous to cause inaccuracy. It could be as subtle as, for example, the vibrations of a CD mechanism inside the product. Any measures which can be taken to isolate the clock circuitry from the external physical vibrations should be taken, as this creates a higher level of clock performance.

Power Supply

The ability of a quartz crystal (or any piezoelectric material) to maintain a consistent oscillation frequency relies on having a stable, interference-free DC signal of the correct specification. In the case of both VCXOs and OCXOs, this means clean DC for the power supply. In the case of a VCXO, even more crucially, the control voltage needs to be stable (in this type of oscillator, the control voltage is used to make fine adjustments to the crystal’s frequency). If there is any variation in the power rails fed to the crystal, the frequency it resonates at will change. In products with a quartz-based clock, designers should always endeavour to have as clean a power supply fed to the crystal(s) as possible, at the correct voltage and frequency for the specification of the region the product is being used in.

Crosstalk

Electronic circuits can generate electromagnetic leakage. This is often seen when running high-rate signals such as digital audio signals through the copper tracks found on PCBs (printed circuit boards). The copper tracks essentially act as antennas, with the digital audio signals being radiated from the board. This interference can have an impact on associated clock circuits if they are in close proximity, negatively impacting the performance of the clock.

The correct way to eliminate this issue is to design the product’s PCBs in such a way that minimises crosstalk. Secondary to this is to ensure that any sensitive parts are separated from those which may cause interference. An even more effective method is to completely remove many potential sources of EM interference from the product, where possible, such as with the use of a Master Clock (a standalone clock with its own dedicated circuitry and power supplies).

Clock Frequency

The ideal way to design the clock inside an audio product is to have two oscillators: one running at direct multiple of 44.1kHz, and the other running at a direct multiple of 48kHz. The reason for this is that almost any sample rates used in digital audio are multiples of these ‘base rates’ (including DSD, which runs at very high multiples of 44.1kHz). If the clock does not use direct multiples of the sample rate it is to be clocking, the maths becomes more complex and the electronics that need to be used to generate the correct frequency are more prone to jitter.

Trying to clock a 44.1kHz signal with a 10MHz clock, for example, would require somehow synthesising 44.1kHz from 10Mhz, which mathematically is not clean. As such, this type of clock will need to use methods such as asynchronous rate conversion to multiply the rate down correctly. These methods invariably result in a ‘dirtier’ frequency spectrum of the clock signal, meaning that the system will be more prone to jitter.

dCS products use two oscillators, running at 2^9 of the base audio rates (44.1kHz and 48kHz), so 22.5792MHz and 24.576MHz. The easy division down to any required rate results in a cleaner clock spectrum and, as a result, less jitter.

Clock Temperature

While clock temperature is not a source of phase noise, it can affect the performance of an oscillator. The resonant frequency of a quartz crystal is inversely proportional to its size and, by extension, its temperature. As the temperature of the quartz increases, it physically expands. As the temperature decreases, it contracts. This causes changes in the resonant frequency of the quartz, as the physical size is now different. Temperature variations in digital systems should therefore be avoided, or the effects mitigated wherever possible.

There have been several methods for counteracting temperature variations inside a crystal oscillator. One approach is to use an industry-standard OCXO. An OCXO aims to remove the temperature variation of the crystal by using a Curie heating element to keep it at a stable temperature. The Curie device is a resistive heater whose resistance increases sharply when it reaches a certain temperature, effectively cutting back the heating power. The temperature will overshoot and then stabilise around the required temperature. When the temperature of the product is not stable (such as when it is powered on from cold), due to thermal delays, there will be some fluctuation in the temperature and, consequently, the frequency as the system ‘hunts’ around the target temperature. Once the crystal’s temperature has stabilised, however, the clock will output a stable frequency.

Another approach is to use a microcontroller-enhanced VCXO, as we’ve done in a number of dCS products. This approach does not use any heating elements to account for temperature variation. Instead, we utilise the large amounts of processing power available thanks to the FPGA-based design of our products to make constant adjustments to the control voltage fed to the VCXO to compensate for temperature changes.

In the case of a dCS Master Clock, such as the Rossini Clock or Vivaldi Clock, these adjustments are based on intensive measurements taken during production. During the production process, we place the clock (and the circuit board the clock is fixed to) into an Environmental Chamber. This chamber measures the clock frequency against the current controlled environmental temperature and records it onto the FPGA inside the product. The temperature is then changed, the clock measured, and the performance again logged. This process is repeated over 18 hours. This enables us to plot exactly how the VCXO in the Master Clock behaves at any given temperature, which the product has a record of.

This data is actioned in the product by adjusting the control voltage which is fed to the VCXO. A higher or lower voltage will create a higher or lower resonant frequency. This, combined with the product’s knowledge of its performance against temperature, ensures the clock’s output frequency is always stable. At any given normal operating temperature, the clock’s output frequency will be consistent.

This is a constant process inside the Rossini and Vivaldi Clocks, with the clock temperature regularly measured, and the control voltage adjusted if the clock temperature has varied. The result is that a new Vivaldi Clock, for example, can achieve an accuracy of above +/- 1 PPM when shipped. Once the clock has stabilised in its environment, the accuracy typically increases to +/- 0.1 PPM.

In the next post, we’ll look at the other main kind of jitter: interface jitter.

Part 3 - Jitter (Interface)

10 Likes

Very interesting, thanks James.
Merry Christmas!

That’s a good description of why clocks aren’t calibrated at home, too. Golly. What a process!

Thanks so much for these posts, dCS people :+1:

Excellent series. One aspect of clocking that I hope you will address has to do with the provision for an externally attached “master clock” for the Vivaldi Clock. What type of clock should this be if used? And what would be it’s overall value with other components, which rely on clocking, within a consumer audio system? I’m thinking here of network switches of maybe CD playback or streaming devices.

Part 3 – Jitter (Interface)

If a product is locking to the clock signal of an external source, such as a CD transport connected to a DAC, interference picked up by digital audio cables between the products can smear the transition times of the clock data within the signal – essentially, changing the point in time where a 0 changes to a 1, or vice versa.

Balanced lines help reduce interference induced in the cables. This is why the AES/EBU format uses 110Ω twisted-pair, shielded cable. This effectively shields the conductors in the cable from most electromagnetic interference (EMI) and flushes any that it picks up to ground, eliminating it from the signal. Any EMI that gets through to the conductors gets phase-cancelled, because each conductor is exactly 180 degrees out of phase with the other. (Since the pairs are run together, any noise will be induced in both conductors in phase with each other and, thus, cancelled.)

It’s important to ensure that a cable has the bandwidth needed for digital signals. The square waves carrying the signal have a very fast rise time between the low and high states (the 0s and 1s). A fast rise time translates to a very high frequency – up in the megahertz range. For this reason, it’s advisable to use good quality 110Ω cable for AES transmission and 75Ω cable for S/PDIF transmission that is specifically designed to carry digital audio data.

When a digital signal is passed through a cable, the cable will, to a degree, act as a filter. A poorly designed cable, which is unfit for use with the interface it is designed for (such as AES3, for example) could potentially filter out high frequencies from the signal before it reaches the DAC from the source device.

This causes an interaction between any two consecutive data bits within the signal, called intersymbol interference. Depending on the relationship between the first and second of any two bits, the transition between the two can be temporally smeared. The ideal clean vertical line of the square wave becomes more sloped, meaning the exact moment a 0 changes to a 1 or vice versa can be blurred. In short, jitter can be introduced purely from the interactions within the data itself.

If the timing data in the audio signal is being used to lock the DAC’s clock to the source’s clock, this intersymbol interference will have a negative impact on sound quality, as it can introduce jitter to the DAC’s clock. However, if the audio system is making use of a Master Clock, and the timing information embedded in, for example, the AES3 signal is no longer being used, the effects of intersymbol interference are negated. While the same filtering effect in the cable and interactions within the data occur, the intersymbol interference does not cause jitter. This is because the Word Clock signal being sent from a Master Clock is regular and does not change like an AES signal does.

It is worth noting that as the PLL used in a dCS product is slow acting, and the clock recovery circuits used are very capable, the effects of intersymbol interference are minimised in cases where the DAC needs to lock to the clock information embedded in the audio signal (such as instances where a Master Clock is not available).

The next post will discuss clock synchronisation, such as how to utilise a Phase Locked Loop to synchronise two different clock domains, like those in a DAC and connected Transport.

Part 4 - Clock Synchronisation

6 Likes

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.

Part 5 – Asynchronous Sources – USB & Network Audio​

10 Likes

Great stuff. This post is missing the link to the subsequent post at the end
Thanks
Rudi

The subsequent post is an explanation on what is dCS Apex…so only few days to read it :laughing:

Part 5 – Asynchronous Sources – USB & Network Audio

Audio sent over an asynchronous format (such as streaming to a smartphone via Spotify, playing content from a NAS via Roon, or playing music from a computer via USB) is, to an extent, the exception to the rules stated in the previous posts, in so much as jitter is not a factor for the audio data, at least until it reaches the endpoint and is converted back to the relevant format (such as PCM or DSD).

With network audio, the interface which is used to send audio data over a network is called TCP (Transfer Communication Protocol). The data which is to be transmitted from one place to another –
in this case a piece of music – is split up into multiple ‘packets’. These packets contain not only the data itself (the ‘payload’), but tags on where it has come from, where it is going, how many packets it is part of and how these packets should be reassembled to get the original data back unchanged.

Take, for example, a track from Qobuz being streamed to a dCS Bartók DAC. If a packet of data is lost or compromised, according to the TCP interface, the Bartók can simply request that packet again. When all the correct packets have been received properly by the Bartók, they are unpacked back to the correct data format (PCM, for example) and buffered before being fed to the DAC. This stage, the unpacking and buffering, effectively removes any timing link between the TCP packets and the resultant audio signal. (Read that sentence again, as it’s very important.)

Once the data has been buffered in the Bartók, the factors discussed above become relevant again. The data is now being directly dictated by the Bartók’s clock and as such, jitter becomes a factor. The accuracy of the Bartók’s clock then controls when the DAC converts the samples back to analogue voltages, so has a direct impact on audio quality. Until it reaches that point, however, jitter is simply not a factor from an audio perspective.

Asynchronous USB audio works in a similar way. There is no timing link whatsoever between the source, such as a computer, and the endpoint such as a Bartók. It does not matter if, while the USB data is being transferred, the bits are not perfectly spaced as a clean square wave. Provided the bits are received by the Bartók correctly (a 1 isn’t misread as a 0, for example) the timing is largely irrelevant. This is because, as with network audio, the data is buffered before being fed to the DAC. It is not until this point that timing becomes a factor, as at this point, it has been converted back from USB format to digital audio (eg PCM or DSD).

9 Likes

Indeed. Thanks for all this James. Superb information.

It means no need for any clocking system before the data are processed by the Upsampler, am I right ?

1 Like

Sounds so to me.

Correct. At least in terms of how clocking is discussed here. A digital device such as a network switch still has a clock but for very different purposes that are nothing to do with audio - the idea of externally ‘clocking’ something that is spitting out asynchronous data like a network switch is a bit of a contradiction.

4 Likes

Does it also means that my expensive Audioquest rj45 Vodka cable isn’t more useful that any cat 6 cable ? I am already sweating in waiting for your answer :laughing:

But I take the opportunity that you don’t sleep yet to tell you that it is a real privilege to sometimes have a chat with the designers of great gear I use every day to listen to music.
I share what Greg wrote in another thread, saying that he trusts the dCS engineers, me too, impatient to hear the new Apex :+1:

From a few of the more objective folks I have spoken to I believe the ethernet cable and switch are not in the critical signal path and won’t impact sound. They make fine audio jewelry. I am not an anti-cable guy I have a full high end loom of interconnects.

2 Likes

I think the detail about buffering is really significant.

While I’ve heard some noticeable differences using high-end switches with other audio equipment, my Bartok seems pretty immune to any noise from the network. Every part of the design seems immaculately thought through and executed.

PS I agree, it is great to have the developers contribute on here :slight_smile:

1 Like

In theory, everything sounds logical…
But still, there are other kinds of problems, since different network equipment affects the final sound quality. To deny this is to deny the experience of the huge number of enthusiasts and the market for audiophile network devices (even if some of them are snake oil)

Hmm, that sounds tautological to me. There may be reasons why poorly constructed networks, network components, non-compliant cables, or noise sources produce audible results in systems, and some of those reasons may be psychoacoustic, and some may even be real, but the presence of a market to sell to those perceptions does not in this hobby prove the reality. And with respect to James’ point, those upstream devices/components/cables/actions do not affect the timing of the (asynchronous) musical information. If one has a problem switch, that is causing an obnoxious ground loop for example, or some other noise, then by all means, one should fix that! But that is quite different from claiming that clocking a network switch makes a difference in SQ. [Full disclosure: I had an EtherREGEN in my Vivaldi speaker system, which I had purchased for its isolation capabilities, and to compare with my GigaFoil 4. And just for shits & giggles, I clocked it with both my Perf10 and Kronos1 reference clocks. Audibly, it produced nothing different from the GigaFoil. But it was fun. Eventually, I removed the ER, because it always ran hot, even on its own little metal stand that I made for it, and it routinely locked up on me, requiring a hard reboot. Those two problems were consistent in both my speaker system and headphone rack.]

2 Likes

An Obnoxious ground loop…Greg I missed you the last mounths, but now I know you are back :laughing:

I learn new english words almost every post you launch…that’s fun :wink:

2 Likes

For this reason, even a full reclock, buffer, and the rest described above does not solve all the problems. This means that the ethernet interface is not absolutely stable and immune.
I have a basic quality switch, a good liner power supply, a recommended certified cable, but one Melco changes the game. I have tried others with varying degrees of success.
I know that some manufacturers have gone a little further and added optical usb, ethernet. I think I already wrote about the experiences of enthusiasts… :thinking: :slightly_smiling_face:

1 Like