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:[EMAIL PROTECTED] Sent: 01 March 2005 12:38 To: Slim Devices Discussion Subject: Re: [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 _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
