PDA

View Full Version : Modifying squeezebox clock



Julian Alden-Salter
2005-03-01, 13:11
Phil,
I take on board what you are saying but unfortunately don't know enough
about the subject to say whether I agree or not. However there are 2 readily
observed phenomena (one purely objective and one arguably subjective) which
say there is something not right about the squeezebox's digital output.
1) The fact that my dac locks on with different qualities of lock when mp3
and flacs are played back. Suggesting that there is indeed some difference
in the spdif data stream between the two formats.

2) The 'subjective fact' that the squeezebox sounded worse than a cd
transport.

If jitter is not the cause of these observations they I'd ask you if you can
propose an alternate reason for them.

Secondly we aren't talking about reclocking the dac. We are talking about
reclocking the squeezebox - specifically taking the spdif output, stripping
the old clock data out and adding a more accurate one to the data stream. If
I understand correctly this is what both the trichord and tent xo3 boards
do.

As for not using a dac, well the analogue output stages and filters inside
the squeezebox are poor compared to that in a decent off board dac. Even
with the jitter / unknown problems effecting the spdif output it still
sounds better than the analogue outs from the squeezebox.

Cheers

Julian.

-----Original Message-----
From: Phil Karn [mailto:karn (AT) ka9q (DOT) net]
Sent: 01 March 2005 12:38
To: Slim Devices Discussion
Subject: [slim] Modifying squeezebox clock

Triode wrote:
> For some science, try the following:
>
>
http://www.essex.ac.uk/ese/research/audio_lab/malcolmspubdocs/C41%20SPDIF%20
interface%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
oscillators.

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.

--Phil

Phil Karn
2005-03-01, 21:08
Julian Alden-Salter wrote:

> 1) The fact that my dac locks on with different qualities of lock when mp3
> and flacs are played back. Suggesting that there is indeed some difference
> in the spdif data stream between the two formats.

What do you mean by "different qualities of lock"? I've had no trouble
with my squeezebox connected optically to a Sony V333ES receiver. Works
fine in both MP3 and raw PCM mode.

There is an important difference between these two modes, though. A
fixed-size buffer in the Squeezebox provides several seconds of network
buffering at MP3 rates, but far less time at the much higher raw PCM
speed. MP3 streams play fine, but I often hear music interruptions in
raw PCM mode when the slimserver is doing other things (e.g., rebuilding
the database.) Since most of my database is in FLAC format and is
streamed in raw PCM format to the Squeezebox, this is a major concern
for me.

Renicing all slimserver-related tasks to a higher priority usually stops
the interruptions, but this is clearly not a very desirable fix
especially since the slimserver sometimes likes to gobble up all
available CPU, e.g., when it's rebuilding the database or when it just
goes out to lunch for no reason.

It's clear that some attention should be given to real-time issues and
thread scheduling priorities in the slimserver. Threads and processes
involved in real-time playback activities should be given higher
scheduling priority, whie background activities like rebuilding the
database should be given a *lower* than normal priority. The
UI/webserver should run at "normal" priority.

Perhaps you're simply having similar problems with buffer underruns when
operating in raw PCM mode?

> 2) The 'subjective fact' that the squeezebox sounded worse than a cd
> transport.

They sound *exactly* the same to me, assuming of course there are no
buffer underruns.

> Secondly we aren't talking about reclocking the dac. We are talking about
> reclocking the squeezebox - specifically taking the spdif output, stripping
> the old clock data out and adding a more accurate one to the data stream. If
> I understand correctly this is what both the trichord and tent xo3 boards
> do.

*Any* external DAC with a S/P-DIF input should do a good job of cleaning
up its input clock. That's the entire purpose of a clock recovery PLL.
If you think that the PLL in a particular external DAC is badly designed
and has too much jitter, then try tightening the bandwidth of its loop
recovery filter. That should work just as well -- if not better-- as
buying an expensive standalone clock regenerator box, and at the cost of
just a few component value changes.

The reason I say this should work even better than the external box is
very simple. If, as that AES paper suggests, tight filtering of the
composite S/P-DIF signal by the transmission line is the root cause of
jitter, then it won't do any good to regenerate the clock in a separate
box only to re-encode it as S/P-DIF and send it over another cable into
the DAC; you'll just reintroduce the jitter! And if you use a high
quality, wideband cable between the clock reconstructor and the DAC to
minimize jitter, why not just use one directly between the Squeezebox
and the DAC and omit the clock reconstructor box altogether?

> As for not using a dac, well the analogue output stages and filters inside
> the squeezebox are poor compared to that in a decent off board dac. Even
> with the jitter / unknown problems effecting the spdif output it still
> sounds better than the analogue outs from the squeezebox.

Really? They sound just fine to me. I just can't get excited over minor
differences in filter design that are highly unlikely to be audible. I'm
old enough to remember all the nonsense about linear phase lowpass
filters when the CD first came out, in 1984. A bunch of us tried
carefully controlled listening tests and *none* of us could tell *any*
difference among players in a blinded test with carefully matched audio
levels -- with one exception. The only one player that we could easily
tell apart from the others was the Sony D-5, the very first "Walkman"
mini-player. It had very noisy analog electronics after the DACs, and
the hiss was easily heard.

A much more valid reason to use an external DAC is when the device whose
DAC you're bypassing is in a system with a lot of digital noise running
around. This can sometimes be true in your garden-variety PC sound card
given that it's plugged into a motherboard with ~100A of supply current
flowing through a high-end Pentium 4 only 10 cm away. But I sincerely
doubt it's true in a small, low power box like the Squeezebox with its
own power supply.

Now it's still possible that there's a ground loop or similar design
flaw in the Squeezebox that introduces noise into the analog outputs,
but I haven't heard anyone complain about that yet and I haven't noticed
any such noise myself. This is in contrast to some older network audio
players, such as the Turtle Beach Audiotron, which has a 3-pin power
cable that can create some very significant group loop noises and where
ground isolation and/or an external DAC with optical cable can make a
big difference in hum and noise level. The Squeezebox comes with a 2-pin
power adapter that, despite its other problems like RFI, doesn't
introduce any ground loops. Except for the occasional stutter in raw PCM
mode, it sounds just fine to me.

Phil

seanadams
2005-03-01, 22:09
On Mar 1, 2005, at 8:08 PM, Phil Karn wrote:

> Julian Alden-Salter wrote:
>
>> 1) The fact that my dac locks on with different qualities of lock
>> when mp3
>> and flacs are played back. Suggesting that there is indeed some
>> difference
>> in the spdif data stream between the two formats.
>>

There is a "just for your information" bit for clock precision in the
s/pdif channel status data - that may be what it is. If so, it has
nothing to do with actual clock precision, it's just a bit that says "I
think I'm a high precision clock" or not. I'm not sure what we send
for this bit but I could check it on my analyzer - at any rate, it does
not affect functionality/performance in any way.

Does your receiver (maybe in the instruction manual) say exactly what
it's reporting?