In testing some of the A2B hardware what appeared to be high jitter on the clocks was observed. While specialized scopes & software are available for making jitter measurements one was not available at the time measurements were needed.
The basic idea is simple enough – measure the clock edges and see if they are all exactly evenly spaced or if they change (jitter) over time. A non-uniform clock fed to an ADC or DAC will produce FM and/or AM effects, as well as raise the noise floor. The effects of the clock jitter depend on the nature of the jitter. Random jitter can have less objectionable audible effects than jitter dominated by a specific frequency. There are many ways for interfering signals to couple in to clock lines to cause problems.
The attached app note looks at using a garden variety DSO (200 MHz BW, 1 Gsample/sec) to see if it can take the place of a $50,000 set up that would normally be wheeled out to investigate a jitter problem.
Luckily, the answer is that within the limits of what most audio systems need, you can get usable results. At higher jitter frequencies (> 2 kHz) when measuring typical bit clocks (i.e. 3 MHz to 24 – MHz) the measurement jitter noise floor is around 20 psec RMS. For lower frequencies it’s around 200 psec RMS due to the need for longer record lengths. For more details read the app note. The software and example files are found in the .zip file.
The Appnote also presents a jitter audibility curve derived from a literature survey, and notes that random broadband jitter has different considerations than jitter with spectral tones in it.
Equipment reviews that focus on measurement will be much more sensitive than the audibility criteria. No criteria is established for measurements as there are too many variables to consider. Some reviewers may consider any jitter related sidebands above the noise floor when sampling or rendering pure tones a sign of bad design. Wideband random jitter will also increase the noise floor, but the amount of that increase depends on the content being used to make the noise measurement. As some tests use 11 kHz (usually as part of an IMD tests with a second tone 1 kHz away) it’s not unreasonable to use that as the assumption for testing. Its higher frequency shows the effect of jitter much more readily than a 1 kHz test tone.
In real life no musical content would have 11 kHz sinewaves at 0 dB; that’s not the point of a test like that. With equipment specs so good uncovering their short comings requires a more aggressive test posture. It’s also truth in advertising, if a product says 10 Hz to 50 kHz +/- 3dB then it better work across that range with no weird “except on Tuesdays” clauses.
Clockworks takes the position that with middle of the road performance, i.e. 110 dB DR, no spectraly related jitter components should be measurable above the noise floor. Likewise the noise floor should meet the stated specifications not just under AES-17 conditions but with a 11 kHz tone as well.
Without going to extraordinary expense for performance above 120 dB DR it can be very difficult to avoid some jitter related components.
Translating that in to jitter requirements is difficult. OTOH predicting the impact of a specific combination of wideband and tonal jitter components is reasonable. One easy to use resource for that is DISTORT available from https://distortaudio.org. Developed by Paul Kane, it was introduced in 2019 via the forum on Audio Science Review. At the time of this post it is still in a Beta release. One open question is that it offers a wide range of FFT window functions (and not documented for cases where the function has parameters), but the correction to the processing gain seemed a little off in some cases, but this was only from eyeballing it. Use the same window choice for all measurements as comparative measurements will be correct. Remember too that some window functions have high side lobes. If investigating jitter effect on noise floor pick a window with low side lobe energy relative to the expected noise floor.
Update/addendum
Came across an ADI app note EE-261 on jitter as it applies to processor clock specifications, but it’s a good introduction to the topic too as it covers TIE which generally isn’t of interest to CPU and SERDES link designers.
Pingback: A2B Transceiver I2S clock jitter analysis - Blogs - Clockworks Signal Processing - EngineerZone