PDA

View Full Version : Modifying squeezebox clock



Christian Pernegger
2005-02-28, 10:55
>I suggest you do some googling to see what jitter actually is and what
>causes it.

Quotes from:
http://www.digido.com/portal/pmodule_id=11/pmdmode=fullscreen/pageadder_page_id=28/

"Jitter is time-base error. It is caused by varying time delays in the
circuit paths from component to component in the signal path." and "The only
effect of timebase distortion is in the listening; as far as it can be
proved, it has no effect on the dubbing of tapes or any digital to digital
transfer (as long as the jitter is low enough to permit the data to be
read."

Jitter is a timing problem, the digital data is not altered. In theory if we
can manage to output the correct data at the exactly right time, there is no
jitter.

>jitter is nothing to do with the buffer.

"Playback from a DAT recorder usually sounds better than the recording,
because there is less jitter. Remember, a DAT machine on playback puts out
numbers from an internal RAM buffer memory, locked to its internal crystal
clock. A DAT machine that is recording (from its digital input) is locked to
the source via its (relatively jittery) Phase Locked Loop. As the figure
above illustrates, the numbers still get recorded correctly on tape,
although their timebase was jittery while going in. Nevertheless, on
playback, that time base error becomes irrelevant, for the numbers are
reclocked by the DAT machine!" and
"I repeat: jitter does not affect D-D dubs, it only affects the D to A
converter in the listening chain"

Buffers can eliminate any jitter you might have picked up up to this point
in the signal path. But you still have to read from the buffer at the exact
right intervals. If your power supply is not clean or the clock is
inaccurate for some other reason you cannot do that and get jitter in the
output. If you use the Squeezebox's DAC, the Squeezebox's clock is relevant,
if you have a good seperate DAC only that matters as far as jitter is
concerned.

>jitter is independent of source format.

There have been multiple messages on this list station that output jitter
from the 'box was a lot higher with .flac files (transferred from the server
as PCM) than with .mp3 (decoded inside the 'box to PCM. Since I don't think
there are two clock chips the clock chip can not account for the difference.
Leaves the processing inside the squeezebox (mp3 decoding vs pass-through)
and the bitrates of the data passed to it.

Yes, to reduce the jitter of .mp3s further you'd need to provide cleaner
power or a better clock chip. But I was looking for ways to bring the jitter
level of uncompressed down to .mp3 levels.

According to my tests the 'box has 256kb of buffer (A 128kbit/s mp3 plays
for a tick over 15 seconds if I pull the network connector in mid-play.) The
same buffer can not even hold one and a half seconds of uncompressed audio.
A CPU spike on the server, a network usage spike or a bit of load can easily
cause interruptions of this magnitude. Network speed is never constant even
under the best conditions.

Even after having googled around a bit I stand by my assumption that the
difference in output jitter is due to the different bitrates and that a
bigger buffer would help towards closing the gap.

Constructive and specific criticism welcome :)

Chris

T
2005-02-28, 11:16
> I stand by my assumption that the difference in output jitter is due to
> the different bitrates

Your assumption is wrong.

Jitter depends solely on the clocking oscillator (unless you have some PLLs
involved, which shouldn't be the case). Buffer over/under-runs can cause
dropped or repeated samples, but not jitter.

Tom

Robin Bowes
2005-02-28, 11:54
Christian Pernegger wrote:
>> Jitter depends solely on the clocking oscillator
>
>
> All other things aside - why is it different for different formats then?
>
>> Buffer over/under-runs can cause dropped or repeated samples, but not
>> jitter.
>
>
> A buffer underrun is just an extreme case of a late sample and the
> buffer can very well be empty for just a fraction of a second.
>
>> Your assumption is wrong.
>
>
> I may well be wrong but just saying so does not make it an argument. I
> say we drop this topic before it degenerates into a flamewar :)

Christian,

Tom is not flaming you - he is merely pointing out (as am I) that you
are wrong.

Sometimes terse responses can be perceived as flames - they're not
intended that way. Believe me, if you'd been flamed you would know about
it :)

Read the link I posted elsewhere in this thread which explains all you
need to know about jitter.

R.

Oh, go on then, here it is again:
http://www.jitter.de/english/engc_navfr.html
--
http://robinbowes.com