View Full Version : Modifying squeezebox clock

Christian Pernegger
2005-02-28, 13:53
>I have that book ("Mastering Audio - the art and the science" by Bob Katz)
>and in it he does
>indeed make a better job of explaining jitter, although it's not brilliant.
>A better explanation is given here [1].
>[1] http://www.jitter.de/english/engc_navfr.html

This was the first link I considered using as a reference. Rather, the
original German version at


but it seemed far from reputable. They try to sell you something. When I
read stuff such as (my numbering)

1 Why do different clamps on a top loading CD transport lead to
different hearing results?
2 Why do some manufacturers of CD-transports use belt drives?
3 Why does a CD-R sound different, although bit-identical?
4 Why do different CD-transports sound different?
5 Why do some manufacturer use stray light inside the CD-player?
6 Why do products that "demagnetize etc..." the CD seem to work?
7 Why do different recording media sound different although they are all

The answer to these questions is mainly:

Clock jitter due to power supply noise.

I have a hard time believing anything in the same document. 6 in particular
is a screamer. Sorry, but I don't buy into green stickers on my speakers
either. :) Show me proof, show me you can ABX it reliably. Next:

1 Why do different digital interfaces sound different, although they
carry exactly the same information?
2 Why do different cable lenghts sound different?
3 Why do some coaxial cables of the same lenght but different
manufacturers sound different?

Either the bit stream is tranmitted intact or it is not. There is no
in-between. Sure, the waveform is distorted but there would have to be in
insane lot of this "line induced jitter" to actually flip bits. Everything
else can be fixed by reclocking and hinges on the quality of the reclocking.

The rest of the article is about recording, which is, espacially with
multiple sources, a whole different thing.

Last not least, from that very site:

Dual stage Clock recovery can also be combined with a data buffer memory.

The first PLL writes to the buffer, and the second PLL reads from the buffer
and tries to keep it always half filled.

If we use a FIFO (first in first out) memory as a data buffer, we have more
time to react to clock variations of the input signal and thus are able to
attenuate lower jitter frequencies. The larger the buffer, the lower the
jitter frequency that can be attenuated.

The disadvantage of the FIFO memory solution is (beside its higher price)
that the output data will be delayed (the buffer has to be half filled
before data is output).

Higher price: What higher price? $150 would buffer you a CD. Even SRAM is
not prohibitively expensive. It's true that buffers delay the output but
they shift it CONSTANTLY meaning you don't want to use this technique for
recording but for playback it's just fine.

Show me scientific proof that using the above quoted jitter reduction method
directly before the DAC (on the same circuit board) the jitter at the DACs
output is influenced by the jitter at the input. Till then I suggest reading
up on "placebo" :)


2005-02-28, 14:10
For some science, try the following:


Phil Karn
2005-03-01, 05:37
Triode wrote:
> For some science, try the following:
> http://www.essex.ac.uk/ese/research/audio_lab/malcolmspubdocs/C41%20SPDIF%20interface%20flawed.pdf

Okay, I've read it. And I'm still not convinced.

Although his math looks fairly solid, he makes a lot of questionable
assumptions that lead to very questionable conclusions. But he also
makes some interesting observations.

The first observation is that significant (i.e., measurable, though not
necessarily audible) jitter appears only when a composite S/P-DIF signal
is severely bandpass filtered. Indeed, his entire paper is all about the
jitter caused by such filtering. This surprised me, as I had initially
assumed that people were complaining about the jitter from timebase

That too-tight filtering can generate jitter is no surprise to me at
all. I'm a digital communications engineer with experience in modem
design, and we call this very well known and thoroughly understood
phenomenon "inter-symbol interference". (See the Nyquist Sampling
Theorem for the math details.) Intersymbol interference is something we
take great pains to avoid, as it can, if severe, impair the
bit-error-rate performance of the modem even at high signal-to-noise ratios.

But here, the author concedes that the jitter isn't so bad as to cause
any bit errors. The *only* problem that remains has to do with jitter in
the recovered clock stream.

By now it should be obvious that if the only significant source of
jitter is bandpass filtering of the S/P-DIF channel, then there is
absolutely no point in replacing the timebase oscillator in a DAC in an
attempt to reduce it. The timebase simply isn't the problem; the
narrowband channel is the problem. Even the cheapest and worst crystal
oscillators have very low phase noise; when you buy a more expensive
crystal, you're mainly buying improved frequency accuracy and long term
frequency stability, not lower phase noise. If the incoming S/P-DIF
signal has a lot of jitter due to tight filtering, then even an
absolutely noise-free local oscillator would be forced, by the error
feedback signal in the clock recovery PLL, to reproduce this jitter at
its output.

This reinforces the comment I made yesterday that if you're truly
concerned about jitter, then the very last thing you want to do is to
attach an external DAC to your Squeezebox. Just use its internal DAC and
you'll get an analog signal with virtually no jitter because there's no
S/P-DIF link and no PLL anywhere in the path. Just a DAC clocked
directly by a crystal, playing out audio data at its own rate. You can't
get better than that.

But back to S/P-DIF. The obvious and preferred solution to the S/P-DIF
jitter "problem" -- if it's even a real problem -- is to simply avoid
transmitting S/P-DIF signals over bandwidth-constrained channels in the
first place. While this may be difficult in some professional
applications where you have to go long distances, e.g., hundreds of
meters, it ought to be easy in most consumer applications where you're
only going a meter or so. Especially if the link is optical, as it often is.

If that's not possible, then I agree with the recommendations in the
paper: tighten the loop bandwidth of the clock recovery PLL in the
receiver so while it will continue to track the incoming clock, it won't
attempt to track the faster jitter components. (Another way to look at
this is that the local reference oscillator won't be forced to follow
the higher frequency components in the incoming jitter.) As the paper
correctly points out, this may slow lock-up or prevent it entirely if
there is an excessive frequency offset between the incoming and local
reference clocks, but a two-step acquire/track PLL can fix this.

But I'm still totally unconvinced there even *is* a jitter "problem" in
the first place. His analyzes tend to assume absolute worst case, and
even so the effect of jitter tends to be right at the level of the
quantization noise in a 16-bit system. Considering that the vast
majority of real-world audio sources, even the very best ones, have a
dynamic range considerably worse than 16 bits, most people would
conclude that jitter is simply not a problem worth fixing with hundreds
of dollars of fancy accessories. And if anyone believes otherwise, all
they have to do is to prove it with carefully controlled studies.
Glowing testimonials and anecdotes from audiophiles won't do.