In the last two posts I have introduced jitter as a digital phenomenon, explained what it is, what it does, how we can measure it, and discussed whether or not we can hear it. All this was started off by the observation that different “Bit Perfect” audio players can sound different, even though all they are doing is using the same hardware to send the same precise data to the same DAC. We postulated that, in the absence of anything else, the only possible mechanism to account for those difficulties had to be jitter. So we took a long hard look at jitter to see if it fit the bill. And maybe it does, but we didn’t exactly explain how software can affect jitter. Before doing so, we are going to take a fresh look at jitter, this time from an analog perspective.

You see, although it is easy to think of digital data in binary terms (it’s either a one or it’s a zero), that we process at some specific instant in time (defined to the picosecond so we can account for “jitter“) – in reality it is never quite so simple as that. Let’s look at a simple circuit, designed to take a digital input and, at a point in time defined by a clock signal, output a certain analog voltage. For the purposes of understanding the operation of jitter, there are two things happening. First of all, the circuit is monitoring the voltage which represents the clock signal, in order to determine when it is ticking and when it is tocking. And secondly, once the clock is triggered, the output circuitry is applying the desired voltage to the output.

We’ll start with the tick-tock of the clock. A clock signal is typically a square-wave waveform. It oscillates sharply between fully “on” (a high voltage) and fully “off” (a low voltage), and it does so very abruptly. Our circuit measures a “tick” when it detects the signal transitioning from low to high, and a “tock” when it detects a transition from high to low. Tick is generally the point at which the clock signal triggers an event, and the function of Tock is generally to mark the point at which the circuit starts looking again for the next Tick. Digital electronics are very easy for the layman to comprehend at a functional level, because the concepts are very easy to visualize. We can easily imagine a square-wave clock signal, and the nice, clean, rising and falling edges of the Tick and the Tock. At some point most of us have seen nice, helpful diagrams. What’s the problem?

A real-world clock signal has some real-world problems to deal with. First of all, we need to look at those high and low voltages that we are measuring. If we look closely enough, we will see that there is usually a lot of high-frequency noise on them. They are not the nice clean square waves we expected them to be. The impact of all this noise is that it gets harder to guarantee that we can distinguish the “high” voltage from the “low“. It is no use getting it right 99 times out of 100. We need to get it right a million times out of a million. The higher the speed of the clock, the worse this gets. But it is quite easy to fix. If the problem is caused by high frequency noise, all we need to do is to filter it out using a Low-Pass Filter. Let’s do that.

Now two things have happened. First, the trace has indeed thinned out, and we can accurately determine whether the clock voltage is “high” or “low”. But now we see that the transitions between high and low now occur at a more leisurely pace. The exact point of the transition is no longer so clear. There is some uncertainty as to when the “Tick” actually occurs. Because of this filtering, there is a trade-off to be had between being able to detect IF a transition has occurred, and exactly WHEN it occurred. If our Low-Pass Filter rolls over at a frequency just above the clock frequency, we do a great job of filtering the noise but it gets correspondingly less certain WHEN the transition occurs – in other words we have higher jitter. The amount of uncertainty in the WHEN can be approximated as the inverse of the roll-over frequency of the filter. The roll-over frequency is therefore normally the highest we can make it without compromising our ability to be certain about detecting the IF. Therefore, if we need be able to function with a higher roll-over frequency and so reduce the uncertainty in the WHEN, we need to re-design the circuit to reduce the noise in the first place.

The take-away from all this is that the presence of high frequency noise is in itself a jitter-like phenomenon.

One way to design an accurate clock is to run the clock “N” times faster than we actually need, and rather than count every Tick, we count every “N” Ticks. We call this process “clock multiplication“, and we can – in principle – achieve an arbitrarily low jitter on our clock by continuing to increase the clock multiplier. This is, in fact, the way all real-world clocks are built. Any way you do it, though, it gets exponentially more expensive the faster the clock gets, due to an increasingly more arduous noise problem. Wickedly so, in fact. If you are DAC manufacturer, it really is a simple question of how much you want to pay to reduce your master clock jitter!

And it’s not just the clock itself that has to be high speed. For example, any circuit anywhere in your DAC that needs to operate such that events can be synchronized to within 1ns must, by definition, have a bandwidth exceeding 1GHz. That, dear reader, is one heck of a high bandwidth. Not only does your clock circuitry have to have GHz bandwidth, so does the converter circuitry which is communicating with it to synchronize its measly 44.1kHz operation with your GHz clock. Otherwise – in principle at least (because nothing is ever so black and white) – you would be wasting the expense you went to in generating your super-clock in the first place. In any case, it becomes a given that a real-world DAC will be constructed with electronics having a bandwidth which – if not necessarily in the exotic territory of GHz – will still be much higher than the sample rates of the conversions it is tasked to perform.

Designing a circuit with RF (Radio Frequency) bandwidth, and having it exhibit good immunity from RF noise, is generally a no-win prospect. When dealing with RF, every problem you solve here results in a new one popping up there. RF circuits are inherently sensitive to RF interference, and so you need to design them – and package them in such a way as to make them immune from the effects of external RF.

External RF is everywhere. It has to be, otherwise your cell phone wouldn’t work. In a circuit, RF does not just flow neatly along wires from one component to the next. It also radiates from the wires and from the components, all the time. And it is not just RF circuits that generate RF. Your house wiring is rife with RF. Just about every electrical appliance you own – all the way down to the dimmer switches on your lights – emits RF. My central heating just turned on – sending a massive RF spike throughout the house, not to mention through the electrical mains line to my neighbour’s house. As a DAC designer, you can do your job diligently to protect yourself from all this, and at least minimize the ability of RF to sneak into your circuit from the surroundings. But you can’t do much about the RF that sneaks in through connections that are designed to transmit RF bandwidths in the first place! Such as the USB and S/PDIF connectors through which your music data enters the DAC.

A USB connector is by design a high bandwidth port. The USB spec calls for it to be so. Within its defined bandwidth, any RF noise injected at one end will be faithfully transmitted down the cable and out the other end. And, in your case, straight into your DAC. This will be so, even if you don’t need all that bandwidth to transmit the music data. The USB connection is indeed a very noisy environment. This is because, in order to just transmit raw data, you are fully prepared to sacrifice timing accuracy (the WHEN) for data accuracy (the IF). Therefore, so long as the amount of spurious RF interference injected into the link is not so much as to compromise the data transmission, the intended performance of the USB link is being fully met. So, if the internals of a computer are generating a lot of spurious RF, there is good reason to imagine that a lot of it is going to be transmitted to any device attached to it via a USB cable. Such as your DAC.

What are the sources of spurious RF inside a computer? For a start, every last chip, from the CPU down, is a powerful RF source. And the harder these chips work – the more cycles they run – the more RF they will emit. Disk drives generate lots of RF noise, as do displays, ethernet ports, bluetooth and WiFi adapters.

So it is not too much of a stretch to imagine that playback software which uses more CPU, more HD access, makes things happen on the display, and communicates over your networks, … it is not too much of a stretch to see how those things have the potential to impact the sound being played on the DAC connected to the computer. Not through jitter, but through RF interference, whose effects we now see can be hard to distinguish from those of jitter.

This, we believe, is the area in which BitPerfect does its thing. Through trial and error, we have established what sort of software activities result in sonic degradation, and which ones don’t. It doesn’t mean we have the exact mechanism nailed down, but it does mean that we have at least the basics of a handle on the cause-and-effect relationships.