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 _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
