PDA

View Full Version : Squeezebox Clock



Mark Jenkins
2004-10-21, 16:45
The digital stream out of my Squeezebox seems to be running at slightly the wrong speed.  My DAC has three lock settings - call them wide, narrower and narrowest.  Whereas a good CD transport can be locked onto at any of the three settings, the Squeezebox can only be locked onto at the wide setting.  From the specs of my DAC this suggests the clock of the Squeezebox is more than 100ppm out and probably even more than 200ppm than the DAC expects for 44.1kHz sampling.  To clarify, I rip full resolution wav files and store and unpack using flac.  Therefore I am outputting Redbook from the server to the Squeezebox, and again Redbook out of the Squeezebox.  The DAC recognises the input as being 44.1kHz - ish, but not close enough to use any lock setting than its adaptive rate setting. 



I am looking for a way to solve this because the sound performance of my DAC is improved a lot if I can use the narrowest setting - since it kicks in a buffer and de-jittering stage that cleans things up quite a bit, even on my CD transport.  Yes, I am one of those audiophiles that want to have the Squeezebox convenience cake, and eat it too via high end sound - all for USD199.



I don't think the problem is jitter.  I have an expensive wee box, a Meridian 518, that I have tried feeding the Squeezebox into before the DAC, and this removes a heck of a lot of the Squeezebox jitter, but passes through the incoming speed.  And yes, I have the same problem regardless of whether the 518 is in or out of circuit, and I have tried replacing all cables, and tried different transports.  All this proved was that the Squeezebox and/or server were the likely culprits.



First a question - is the clock speed determined by the Squeezebox or by the server?  Both are possible in theory, it seems to me.  If it is determined by the Squeezebox then I would need to look at replacing the crystal in the Squeezebox, or upgrading using a kit like those marketed by Trichord or others.  However, it is possible that the Squeezebox's clocking is adaptive to the incoming rate and it passes through the rate determined by the server - the buffer is just to reduce jitter.  In which case improving the Squeezebox clock will reduce jitter further but not correct the speed.



If it is the server, then does anyone have any idea how I can improve that?  Could it be that I have to ditch using flac?



My technical understanding is not spectacular, so I am unclear whether the reported pitch error in the latest release is potentially a cause of this.



Mark Jenkins








Find the music you love on MSN Music. Start downloading now!

Michel Fombellida
2004-10-21, 18:22
Mark,

Look at this bug report: http://bugs.slimdevices.com/show_bug.cgi?id=416
it could be related to your issue. The bug was confirmed my Sean. You could try
with an MP3 file and see whether the lock is better.

Note that once the clock is stable in my case, I am getting a very good lock
with both a dCS Purcell and an Apogee Big Ben.

Michel

Mike Reeve
2004-10-21, 19:36
Michel Fombellida <mf22433@...> writes:

> Note that once the clock is stable in my case, I am getting a very good lock
> with both a dCS Purcell and an Apogee Big Ben.

Mark

To follow up on what Michel reports above:
I have the output of the Squeezebox connected to a Genesis Digital Lens
(a device from the same era as the Meridian 518
which buffers a second or so of the data in RAM and then clocks it out
with a very accurate and stable clock).
The Digital Lens also measures the error of the clock in the incoming data
and once the Squeezebox has stabilised it registers a pretty consistent
18 ppm error (which as has been noted before
is better than many so called audiophile transports ...).
So I suspect that what you are seeing is a side effect of
the (relatively) long time that it takes the Squeezebox's clock to stabilise
in PCM mode.

Sean has indicated that this (like the L/R channel swap problem)
is an issue with the DSP that they are using
and that they will work with the supplier on fixes ...

Regards

Mike