Why rubidium clocks are a myth

Join Our Community Subscribe to Paul's Posts

In yesterday’s post Storage Tankswe concluded that if the reduction of jitter was our goal, as it should be in digital audio, we would not be happy with a Band Aid, like those found in the majority of the early de-jittering boxes of the 1990’s. The reasons were pretty clear: using a “regulator” to lower jitter worked, but not as well as we wanted. Those regulators were PLL’s (Phase Locked Loops) which are essentially a fancy low pass filter. I know this is more technical than we want, so suffice it to say, these primitive filters reduced large amounts of jitter above a certain point, but like any filter they didn’t remove everything we don’t want.

As in our water analogy, what we really wanted was a storage tank or buffer, placed between the CD player’s digital output and the input to our DAC. But to be more specific, what we REALLY wanted was a new, jitter free signal. The only way to get that from a digital audio signal that is already full of jitter is to throw away the clock that is causing all this jitter and provide a new one that hasn’t any.

Remember that jitter is our audio data arriving at the wrong time. But who’s keeping track of the time? Well, our clock of course. Just like the train conductor looking at his watch to keep the trains on time, the term “on time” is relevant only to some sort of reference time keeping device. And this happens to be called a clock. The clock isn’t really a clock as you might think of. Clocks we are familiar with keep a record of passing time with their seconds, minutes and hour hands or displays. But a digital audio clock doesn’t care what the actual time is. Our audio clocks care only about the pace and keeping that pace constant. Like a clock that only shows seconds, not minutes or hours.

You’ve read about DACS that use fancy rubidiumbased clocks? These are essentially atomic clocks that are uber accurate. But their level of accuracy is meaningless in digital audio. And don’t let anyone tell you differently. A rubidium clock’s accuracy is long term, meaning the time it is keeping will be the same a year from now. But for audio purposes we could care less. Our aural memories aren’t going to know if the clock rate is slightly faster or slower over a long period of time, probably not even over a minute or two, let alone a year or a decade. The reason DACS using rubidium or expensive clocks sound so much better isn’t the increased long-term accuracy, but most likely because of the care their engineers lavished on them in terms of wiring, shielding, power supplies and so on. What I can tell you for sure is there’s nothing magical about their long term accuracy when it comes to audio.

But pacing is important. No, let me say that a different way. Pacing of the clock, from one clock cycle to the next, is CRITICAL to sound.

So what we want in our digital reduction box we’re building is a perfectly accurate clock that keeps its pace the same for minutes at a time. And we want a clock that is unaffected by any external factors like the power it is using to run and the signal coming into the box the clock lives in. This is the clock we’re looking for. And once we have this clock working perfectly, we’d like to use it to send out our audio data to the DAC. But we discover there’s a problem.

The audio data being sent to us by the CD player is not only full of jitter (short term timing problems), but it also has relatively long term speed problems. The data and the clock of our CD player runs slow and then fast relative to our expectations. In fact, that data runs so much slower and faster than our perfect clock that it is impossible to synchronize the two without messing up our perfect clock’s performance. So while we really don’t care about the long term speed problems when it comes to listening, we do care when we try and synchronize one clock to another.

When we had this problem with our water system we went to a storage tank to buffer the incoming water speed differences. Now we’re going to use that same technique with our audio data once we strip out its clock and throw it away.