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.

[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...r_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.