Actual jitter measurements!

[seanadams]

Measurement setup:

Stanford Research Systems model SR-620
Squeezebox2
BNC connector grounded at s/pdif coax, wired to internal 11.2896 master clock.
3' RG59 cable

The one-shot measurement resolution of this unit is 25 picoseconds, but with enough samples, its 1ps LSD display is enough to consistently measure the impact of phenomena as small as CPU activity (as speculated in the FLAC thread). Scope probes did not give consistent readings so I soldered a BNC directly to the board - at this resolution even slight changes in the position of the probe will throw the measurement off by 100ps or more, so a solid connection is definitely needed.

These are standard deviation for 10,000 samples measured at DAC input. In addition to disabling the second oscillator, I also tested some different power supply configurations but those did not show any changes in sigma. However pk-pk measurements shown on the dscope analyzer (for the s/pdif out) did show differences - I haven't investigated that disparity yet. Anyway here's the data from the SRS-620:

Unmodified SB2, playback paused: 65 ps

SB2 with 12.2880 crystal lifted:

playback paused: 55 ps
playing AIFF: 57 ps
playing FLAC: 57 ps
playing mp3: 58 ps

Finally:

Measured at the oscillator: 43 ps

A couple screen shots below (settings are identical for both measurements). Here's how to read these: the vertical line indicates an arbitrary cursor position (rel=48.797ns). The mean measurement is indicating the distance from this value. BTW the nominal value here would be 1/11.2896/2=44.289ns. The difference does not indicate any imprecision in frequency, but rather that the duty cycle is not exactly 50%.

"sigma" is the number we're most interested in. At the bottom, note the scale is 100ps/div. You can see the base of the curve is about 3 divisions wide, indicating pk-pk jitter is about 300ps. A tighter distribution (less jitter) is indicated by a taller, narrower histogram.

http://www.seanadams.com/jitter_pics/1.jpghttp://www.seanadams.com/jitter_pics/2.jpg

[Mark.Bennett]

Hi Sean,

This is interesting data. Do you have equivalent data when
the SB is actually playing music?

The ongoing discussion is about the impact of different
processing algorithms on the jitter. If you can show that
the difference between play and pause is negligible then
the difference between wav and flac will surely also be
insignificant.

Mark.

On Mon, 2005-08-22 at 16:17 -0700, seanadams wrote:
> Measurement setup:
>
> Stanford Research Systems model SR-620
> Squeezebox2
> BNC connector grounded at s/pdif coax, wired to internal 11.2896 master
> clock.
> 3' RG59 cable
>
> The absolute accuracy of this unit is specced at 25 picoseconds, but
> with enough samples, it's 1ps of resolution is enough to consistently
> measure the impact of phenomena as small as CPU activity (as speculated
> in the FLAC thread). Scope probes did not give consistent readings so I
> soldered a BNC directly to the board - at this resolution even slight
> changes in the position of the probe will throw the measurement off by
> 100ps or more, so a solid connection is definitely needed.
>
> These are standard deviation for 10,000 samples measured at DAC input.
> In addition to disabling the second oscillator, I also tested some
> different power supply configurations but those did not show any
> changes in sigma. However pk-pk measurements shown on the dscope
> analyzer (for the s/pdif out) did show differences - I haven't
> investigated that disparity yet. Anyway here's the data from the
> SRS-620:
>
> Unmodified SB2, playback paused: *65 ps*
>
> SB2 with 12.2880 crystal lifted:
>
> playback paused: *55 ps*
> playing AIFF: *57 ps*
> playing FLAC: *57 ps*
> playing mp3: *58 ps*
>
> Finally:
>
> Measured at the oscillator: *43 ps*
>
> A couple screen shots below (settings are identical for both
> measurements). Here's how to read these: the vertical line indicates an
> arbitrary cursor position (rel=48.797ns). The mean measurement is
> indicating the distance from this value. BTW the nominal value here
> would be 1/11.2896/2=44.289ns. The difference does not indicate any
> imprecision in frequency, but rather that the duty cycle is not exactly
> 50%.
>
> "sigma" is the number we're most interested in. At the bottom, note the
> scale is 100ps/div. You can see the base of the curve is about 3
> divisions wide, indicating pk-pk jitter is about 300ps. A tighter
> distribution (less jitter) is indicated by a taller, narrower
> histogram.
>
> [image: http://www.seanadams.com/jitter_pics/1.jpg][image:
> http://www.seanadams.com/jitter_pics/2.jpg]
>
>
--
"The biggest problem encountered while trying to design a system that
was completely foolproof, was, that people tended to underestimate the
ingenuity of complete fools." (Douglas Adams)

[Triode]

Hi Sean,

Out of interest, have you measured what happens if you don't send the spdif though the buffer chip - i.e. disconnect or hardwire to dc in the Xilinx [probably such that the spdif output is low and hence not sourcing current for the output potential divider]. This should minimise the switching currents in the buffer.

For reference one of the after market clock guys claims 3ps rms jitter (3sigma rather than 1sigma) [taken from www.tentlabs.com]. So perhaps there is potential to futher improve with expensive after market clocks, but we are already getting low jitter in comparison to lots of digital gear.

Adrian

[Dave D]

So perhaps there is potential to futher improve with expensive after market clocks, but we are already getting low jitter in comparison to lots of digital gear.

That's an understatement:) In the >10Gb/s equipment we build, we use (for meeting SONET requirements), very high accuracy, very low jitter oscillators, and then apply digital jitter attenuation techniques; the components for which easily exceed the (probable) COGS of a Squeezebox2. The result is a reference clock with jitter at sub-6ps rms. That also is with excruciating detail paid to layout of the board and routing.

Sean, if your jitter distributions are not Gaussian, i.e. if there is enough deterministic jitter (from power supplies, for example) present, it makes sense that you could see the same sigma but different pk-pk values. This is consistent with making changes to the power supply, since one would expect that you would be changing the Dj component of the the jitter. If the jitter is not Gaussian, the sigma value is not very useful. The first jpeg in the links you posted definitely looks to have a "leftward" skew. Actually both of them do.

Also, of course, you would have to have the same number of samples in each measurement to see the same pk-pk values, since random jitter is unbounded. You probably know all this, but here's a link for others reading the thread:

http://www.mtron.com/pdf/contentmgmt/oscillator_jitter_basics-2.pdf

Additionally, I have seen large (percentage-wise) differences in jitter given by different instruments, when pushing the limits of those instruments (comparing results from Agilent and Tek scopes, for example). Rj/Dj separation results are always different since the companies use different techniques for calculating the numbers.

Finally, you are to be commended for achieving such a low rms jitter in a low-cost box like this. The numbers you measured are extremely low!

[void]

For reference one of the after market clock guys claims 3ps rms jitter (3sigma rather than 1sigma) [taken from www.tentlabs.com]. So perhaps there is potential to futher improve with expensive after market clocks, but we are already getting low jitter in comparison to lots of digital gear.

Adrian

Thanks for the measurements!

Be careful with installing internal clocks (and superregulators), they don't always bring an improvement. Watch out for noise, EMI/RF, ground loops.
Imo proper implementation is difficult and has to be tuned to each device, otherwise it's a lucky shot. Measuring is important, but jitter is more than a number, jitter spectrum/patterns are extremely complex, it's difficult to predict the sound. Always compare with your ears too (if you want do to serious modifications you need at least 2 units, don't fool yourself, I've heard way too many theoretically good looking but bad sounding modifications).

Often we get better results by simply changing the layout of the standard clock: move the X-tal as close as possible to the DSP pins (you can hear an improvement with the smallest changes, less than 0.5mm), also relocate the 2 caps as close as possible and symmetrically. Use a good decoupling cap for the supply, as close as possible to the supply pin and ground. (I haven't checked the SB2 yet.)

Sean, what kind of power supply configuration are you using for the MAS35x9F? To lower noise and jitter I'd like to get rid off all switching converters, especially the internal ones. I guess the performance will improve a lot just putting a small 3pin regulator with good cap on each supply pin.

[Mark.Bennett]

OK message to self - make sure you don't post stupid replies
without reading the message you're replying to properly.
Just ignore me - which is what you all seem to be doing anyway.

On Tue, 2005-08-23 at 08:13 +0100, Mark Bennett wrote:
> Hi Sean,
>
> This is interesting data. Do you have equivalent data when
> the SB is actually playing music?
>
> The ongoing discussion is about the impact of different
> processing algorithms on the jitter. If you can show that
> the difference between play and pause is negligible then
> the difference between wav and flac will surely also be
> insignificant.
>
> Mark.
>
> On Mon, 2005-08-22 at 16:17 -0700, seanadams wrote:
> > Measurement setup:
> >
> > Stanford Research Systems model SR-620
> > Squeezebox2
> > BNC connector grounded at s/pdif coax, wired to internal 11.2896 master
> > clock.
> > 3' RG59 cable
> >
> > The absolute accuracy of this unit is specced at 25 picoseconds, but
> > with enough samples, it's 1ps of resolution is enough to consistently
> > measure the impact of phenomena as small as CPU activity (as speculated
> > in the FLAC thread). Scope probes did not give consistent readings so I
> > soldered a BNC directly to the board - at this resolution even slight
> > changes in the position of the probe will throw the measurement off by
> > 100ps or more, so a solid connection is definitely needed.
> >
> > These are standard deviation for 10,000 samples measured at DAC input.
> > In addition to disabling the second oscillator, I also tested some
> > different power supply configurations but those did not show any
> > changes in sigma. However pk-pk measurements shown on the dscope
> > analyzer (for the s/pdif out) did show differences - I haven't
> > investigated that disparity yet. Anyway here's the data from the
> > SRS-620:
> >
> > Unmodified SB2, playback paused: *65 ps*
> >
> > SB2 with 12.2880 crystal lifted:
> >
> > playback paused: *55 ps*
> > playing AIFF: *57 ps*
> > playing FLAC: *57 ps*
> > playing mp3: *58 ps*
> >
> > Finally:
> >
> > Measured at the oscillator: *43 ps*
> >
> > A couple screen shots below (settings are identical for both
> > measurements). Here's how to read these: the vertical line indicates an
> > arbitrary cursor position (rel=48.797ns). The mean measurement is
> > indicating the distance from this value. BTW the nominal value here
> > would be 1/11.2896/2=44.289ns. The difference does not indicate any
> > imprecision in frequency, but rather that the duty cycle is not exactly
> > 50%.
> >
> > "sigma" is the number we're most interested in. At the bottom, note the
> > scale is 100ps/div. You can see the base of the curve is about 3
> > divisions wide, indicating pk-pk jitter is about 300ps. A tighter
> > distribution (less jitter) is indicated by a taller, narrower
> > histogram.
> >
> > [image: http://www.seanadams.com/jitter_pics/1.jpg][image:
> > http://www.seanadams.com/jitter_pics/2.jpg]
> >
> >
--
"The biggest problem encountered while trying to design a system that
was completely foolproof, was, that people tended to underestimate the
ingenuity of complete fools." (Douglas Adams)

[Mark.Bennett]

So, with a sensible reply this time (I hope).

> Unmodified SB2, playback paused: *65 ps*
>
> SB2 with 12.2880 crystal lifted:
>
> playback paused: *55 ps*
> playing AIFF: *57 ps*
> playing FLAC: *57 ps*
> playing mp3: *58 ps*
>

The evidence seem to indicate that the impact on the jitter
of playing FLAC vs AIFF is insignificant.

Given that the stream is bit accurate then any other suggestions
on what phenomena can affect the transfer of digital data
between the SB2 and an external DAC?

--
"The biggest problem encountered while trying to design a system that
was completely foolproof, was, that people tended to underestimate the
ingenuity of complete fools." (Douglas Adams)

[seanadams]

Hi Sean,

This is interesting data. Do you have equivalent data when
the SB is actually playing music?


You saw those numbers for playing different formats right? I only tested those cases on the modified one but will have another look at the unmodified sb2 also. Mainly I was just trying a bunch of things to figure out what had the most measurable impact in these tests.

Weeks could be spent just trying different test cases. The most interesting thing so far I think is that power supply changes affect pk-pk but not sigma, and disabling the second crystal affect sigma but not pk-pk (good explanation for this above). I'm trying to narrow down the search space and identify the biggest wins. Based on this data I don't think CPU activity is really worth digging into.



The ongoing discussion is about the impact of different
processing algorithms on the jitter. If you can show that
the difference between play and pause is negligible then
the difference between wav and flac will surely also be
insignificant.

Mark.


Yep, it was an interesting idea, but it really doesn't look like CPU activity is anything to worry about.

[seanadams]

Sean, what kind of power supply configuration are you using for the MAS35x9F? To lower noise and jitter I'd like to get rid off all switching converters, especially the internal ones. I guess the performance will improve a lot just putting a small 3pin regulator with good cap on each supply pin.

SB1 uses a linear reg for all the 3v3 stuff. I would not bother trying to hot rod the digital side of SB1 though - there are known issues in the Micronas chip which cause clock imprecision. Also its clock is PLL driven so it is unlikely that optimizing the external clock source would have a huge impact - I would expect the PLL's jitter to dominate. Just guessing though - I haven't actually done any of these tests on SB1.

[NealG]

Also its clock is PLL driven so it is unlikely that optimizing the external clock source would have a huge impact - I would expect the PLL's jitter to dominate. Just guessing though - I haven't actually done any of these tests on SB1

In my subjective experience there is a huge benefit in replacing SB1's external clock with a low jitter one. Subtle it is not IMHO.

[void]

SB1 uses a linear reg for all the 3v3 stuff. I would not bother trying to hot rod the digital side of SB1 though
Thanks, I was under the impression that the SB2 used this chip too, I'm glad hear it's not :) Can you tell what's used in the SB2?



> playback paused: *55 ps*
> playing AIFF: *57 ps*
> playing FLAC: *57 ps*
> playing mp3: *58 ps*
>
The evidence seem to indicate that the impact on the jitter
of playing FLAC vs AIFF is insignificant.
Be careful with this conclusion. Jitter is not a number, it's a complex spectrum over a wide frequency range that's constantly modulated in a patterns that have an influence on what we hear. The modulations that correlate to the music signal (in the audioband) seem to sound more unpleasant. It's likely that with FLAC decoding the noise patterns correlate slightly more to the music.

Different noise patterns in the jitter spectrum give a different sound. F.i. with a normal CD-player there's a slight difference in the jitter spectrum between repeat on and repeat off.
Even professional studio equipment like the Apogee Big Ben Master Clock suffers from these problems. It's jitter pattern changes when you change settings that shouldn't be related. This was discovered because someone heard a difference after a setting was changed on another output!

[seanadams]

Thanks, I was under the impression that the SB2 used this chip too, I'm glad hear it's not :) Can you tell what's used in the SB2?

There is no separate DSP chip in SB2. All the DSP is our own code now, running in the main processor, so we're not constrained by any vendors.

[MarcBernard]

Very interesting measurements indeed.

For anyone interested, the subject of jitter and its audibility is well discussed in the literature with one Julian Dunn being the recognized expert. Here is an excellent application note detailing this very topic...

http://www.audioprecision.com/bin/tn23.pdf

Another set of gentlemen, Eric Benjamin and Benjamin Gannon conducted research on test subjects to determine the minimum audible limit of jitter. They found it to be 10ns rms with test tones and 20ns rms with music.

Lest you not be convinced by mere listening panel observations, one can determine the absolute theoretical audibility of jitter by simply requireing the error induced by jitter to be lower than the quantization level of the format...namely 16 bits with the worst case input signal...a fullscale 20KHz sinusoid.

Let V(t) = A*sin(w*t).
Now differentiate to find the max slew rate

dV(t)/dt = A*2*pi*f*sin(2*pi*f*t)

The max slope of a sinusoid is 1 and therefore the max slew rate is

2*pi*f*A

Let A = 325768 (max fullscale signal)
f = 20000

which gives a max slew rate of 4.11 bits/ ns

and thus if the jitter is less than 1/4.11e9 = 243ps peak then there cannot be a single LSB change. Now this is somewhat arbitrary and does not consider sideband modulation due to the spectral content of the jitter and the fact that humans can hear tones that are deeply buried in noise. The accepted theoretical dynamic range of the compact disc format is 120dB when properly dithered. Thus one could require the jitter be another 24dB lower (the quantization noise for 16 bits = 16*6.02 = 96dB) or 244ps / 15.8 = 15.4ps.

In any event, the jitter of the Squeezebox 2 is very low indeed.

Well Done Slim Devices!

[ackcheng]

Would changing the clock inside the SB2 to a low jitter one like Tent XO further reduce the over jitter?

[seanadams]

Would changing the clock inside the SB2 to a low jitter one like Tent XO further reduce the over jitter?

Does anyone have real data on the tent oscillators? I can't imagine they're anything but re-branded off the shelf oscillators with the words "low jitter" printed on them. I mean, I'm sure they did some testing to find good oscillators, but their web site doesn't suggest there's any special sauce in there...

[Patrick Dixon]

Does anyone have real data on the tent oscillators? I can't imagine they're anything but re-branded off the shelf oscillators with the words "low jitter" printed on them. I mean, I'm sure they did some testing to find good oscillators, but their web site doesn't suggest there's any special sauce in there...I think they are custom designed discrete circuits rather than re-branded off the shelf. AFAIK they have multiple PSU regulation/voltage buffering, and although I've never seen or heard one, they seem very well regarded.

[Triode]

Does anyone have real data on the tent oscillators? I can't imagine they're anything but re-branded off the shelf oscillators with the words "low jitter" printed on them. I mean, I'm sure they did some testing to find good oscillators, but their web site doesn't suggest there's any special sauce in there...
Yes I think this is probably true... I think the good performance comes from the right oscillator with a very quiet psu. I've seen Tent and Trichord Research (UK) use encapsulated oscillators with dedicated psu. Others Audionote, LC Audio use a descrete oscillator with low noise psu.

I suggest you look round on diyAudio. LC audio (Lars Clausen) posted the schematics for his older series of low jitter clock a while back [actually the one I have in my CD transport] Elso Kwak also posted a descrete circut. Tent is more careful about the info though.. There was also some discussion about VapleyFisher oscillators on there a while ago [http://www.diyaudio.com/forums/showthread.php?s=&threadid=31661&perpage=10&highlight=&pagenumber=1 - VF140] - perhaps you could get some samples Sean (and send me one!)

Adrian

[NealG]

Guido Tent is a very approachable and knowledgeable guy, why not ask him directly Sean.

[Triode]

Agreed I've purchased stuff from Guido before, but I suspect he may not be keen on giving out his component sources - indeed I think he went though a phase of removing the part numbers from the ICs used...

[Andrew L. Weekes]

Interesting measurements Sean, if you still have access to the measurement apparatus, I'd be interested to see those jitter measurements replicated at the DAC clock input.

I wouldn't be surprised if the CPU / internal digital activity had a greater effect at that point, since you then have the cumulative effects of the additional circuitry and the PSU interactions (some of which is related to CPU activity, I suspect) on that same clock signal.

I'd tend to agree with MarcBernard's observations too, that you can generally assume a 120dB dynamic range + reserve margin when choosing acceptable jitter specs whether the system actually acheives this in measurement or not.

Certainly my experience is that anything to reduce jitter is audible, even in the best engineered of devices, even when at very low levels already. I'm not convinced of the evidence cited by the late Julian Dunn, or the other figures quoted. The reality is jitter is one of the most critical issues to deal with, in my view, from a sound quality perspective, certainly my onw mods on an SB2 confirm that improvement on those already good figures, is clearly audible.

Part of the reason for this is the effects produced by jitter are those the ear is most sensitive too, it's like the difference between aboslute distortion figures and distortion spectra - hgh order distortion is far more audible than even quite high levels of low-order distortion.

One thing that is important though is the jitter spectrum - it's one of the things Guido has openly talked about, he openly admits the clocks he sources are not specially designed, but they have been chosen from a large range of candidates, all of which sounded worse, as much due to the different jitter spectra as any absolute jitter number.

As mentioned, Guido is very approachable and reasonably open, commecial senitivities aside, so it may be worth dropping him an email, or reading some of his output in places like diyaudio.com.

Good stuff though,

Andy.

[seanadams]

I'd be interested to see those jitter measurements replicated at the DAC clock input.



These were in fact taken at the DAC input, except the last one which was taken at the hcu04.

It is also possible to see a jitter histogram for the s/pdif output using this device, but since the pulse widths obviously are different for ones vs zeroes, the sigma reading is not useful. The shape and size of the distribution looks very similar to the internal clock.

I didn't see an obvious trick for measuring a manchester signal - I suppose it could be done either by taking the raw data from the instrument by rs232 and then pulling out only the 1ui pulses, or otherwise maybe there's some way to do it using the external arm/gate input with another signal tapped from the s/pdif encoder...

[Andrew L. Weekes]

These were in fact taken at the DAC input, except the last one which was taken at the hcu04.

I was tired when I read your post - now it's obvious, sorry!

Interesting then, it seems there's around 10ps or so added by the circuitry / traces between the clock and the DAC, which is pretty good, but explains the audible benefit of the direct feed I've now implemented, which has made this little unassuming box sound rather marvellous and very engaging!

It might be interesting too to try a linear reg dedicated to the 'U04, in order to see the benefits of that, which I would expect to be clearly resolvable, although one does need to implement it with care to optimise results*.

Great stuff, thanks for sharing it!

Andy.

* re-reading it looks as if you may have tried this - the pk-pk change is probably simply down to the spectra of the PSU noise, with the skirts being affected more than the main distribution of jitter?

[BFitz]

Measurement setup:

Unmodified SB2, playback paused: 65 ps

SB2 with 12.2880 crystal lifted:

playback paused: 55 ps


Sean - Do you know what impact removing the 12.2880 crystal will have on receiving internet radio stations? I'd like to do this mod, but not if it means I lose lower bit rate internet streams from Shoutcast and so on. Are those all converted to 44.1 ?

BTW, nice jitter measurements, I'll see if I can eventually do some of my own on the SB2.

Bob

[seanadams]

Sean - Do you know what impact removing the 12.2880 crystal will have on receiving internet radio stations? I'd like to do this mod, but not if it means I lose lower bit rate internet streams from Shoutcast and so on. Are those all converted to 44.1 ?

BTW, nice jitter measurements, I'll see if I can eventually do some of my own on the SB2.

Bob

Don't do it if you listen to Internet radio - many stations use 32KHz sample rate, which we resample to 48KHz

[seanadams]

BTW those jitter measurements are probably overstated by as much as 100%. I had the intrument set to determine the trigger voltage automatically, which results in it choosing the lowest point on the slope where it can repeatably trigger. At the middle of the slope (1/2 vcc, roughly where a cmos input would trigger and the point of fastest dv/dt) it measures in the low 30s which is approaching the measurable limit for the system. I did not repeat all the measurements with this setup but if I do spend some more time looking at this in the future, I will share the results.