We’re writing a lot about it at the moment: jitter. But yes: anyone getting into digital audio cannot avoid jitter. We were curious this time about how much influence a source has when connected to the d/a converter via spdif. We grabbed the Sonnet Pasithea and a few sources and locked ourselves in the lab for a few days.
Yes, we know: digital is digital…. ones and zeros… As long as those get through the cable, there’s nothing wrong. Right?
In a sense, that’s true, of course. With computers, the ones and zeros just have to get from A to B. If that works, it’s fine. A file can be copied from one disk to another just fine without any loss. With a network, ditto: as long as the data packets arrive, nothing is wrong. Fortunately: otherwise the Internet would be constantly broken.
Timing
With audio it is slightly different. It’s not just about the ones and zeros. It is – above all? – timing. A clock controlling the dac determines when those ones and zeros are converted to a certain voltage. A dac does that 44,100 times per second at CD quality. Or 96000 times per second with 24 bit / 96 KHz high-res audio material.
Now, no clock is perfect. Every clock ‘jitters’ a bit and every clock suffers from (a bit of) ‘phase noise’. Phase noise is measured in the frequency spectrum. Jitter we measure in the time domain. These are two ways of looking at clock anomalies. We explained this in a bit more detail in this article on the influence of network cables.
Spdif – the source is leading
In most audio systems we are talking about digital sources. The serious enthusiast will have a separate d/a converter in the hifi rack. Or may have an amplifier with a serious d/a converter and thus digital inputs.
Here’s the thing: with spdif, the source is leading and therefore handles the clock. With USB and I2S, the d/a converter is leading. But since the bulk of users will use a coaxial, optical or perhaps BNC or AES input, we are talking about spdif. And in that case, the source is leading: it provides the clock signal.
We were curious how much impact that has on the clock and jitter in the d/a converter. We are now in 2024 and with the robust spdif receivers and reclocking, that should have no impact at all, right?
Spoiler: it still matters! Quite a lot, in fact!
The test setup
We put the Sonnet Pasithea in our measurement box for this test. The Sonnet uses a modern spdif receiver from AKM. To measure the clock signal, we put an active probe at a measurement point in front of the clock. This clock controls the dac modules and is thus directly responsible for the reproduction of the music. The output of the probe goes to the Aeroflex PN9000.
As a reference, we use an Aeroflex SGD3 generator. This uses the PN9000’s clean 10MHz crystal as a reference (bottom left OK butting is green, meaning a REF clock is locked). This really makes a huge difference in performance we have noticed.
As sources we have a Volumio Rivo and a Metrum Acoustics Ambre. The Ambre has two nice Tentlabs clocks internally. We’ll see the benefits of these later. We also grabbed a Mutec MC3+ and a Mutec REF10-120 for this little investigation. We measure the Ambre standalone as well as through the Mutec MC3+ with and without the REF clock.
We have to play music to activate the Pasithea’s “dac clock. For this test we grabbed a high-res track: 24 bit / 96 KHz. That results in a dac clock of 6.14 MHz, as shown in the picture of the Aeroflex SGD-3.
Phase noise
We were a bit shocked when we saw these results. What a difference! Especially close to the carrier – the main frequency of 6,144 MHz – we see significant differences. Because we could hardly believe it, we measured several times.
A REF-Clock helps
Interestingly, the Ambre without a Mutec MC3+ performs better close to the carrier. The Tentlabs clocks perform better there than the Mutec MC3 (without a REF-clock). This manifests itself immediately in less jitter. However further on, the Ambre with MC3+ does dip below the Ambre without reclocker.
If we connect the REF10-120 to the Mutec MC3 it is a totally different story. What a huge difference: the phase noise plunges from about -75dBc/Hz (Ambre without Mutec MC3 ) to -92 dBc/Hz. The difference between the MC3 with and without a REF10-120 is even almost 30 dBc/Hz. In short: an external REF helps tremendously.
For comparison, we took another decent Volumio Rivo streaming bridge and connected it to the Sonnet Pasithea. We see that this one slightly increases the Allan Variance. An Sbooster power supply helps with jitter though. That drops by 2ps. An obvious difference. And audible as well.
Bonus
We got some more measurements from Cees Ruijtenberg who managed to visualise something interesting with an FFT measurement. What you see from left to right is music modulation on the clock signal. This also manifests itself in jitter. And this jitter / modulation must be coming from the spdif receiver, because it is completely gone if we use the I2S-interface. This is not odd, because then the DAC is leading and not the source. Interesting to see that so clearly!
Conclusion
Even in this digital age, the source is and remains incredibly important. Indeed, in the case of spdif, the source controls the clock. The PLL of the receiver chip in the dac must lock onto this signal. If the source’s clock is full of jitter, this will undoubtedly manifest itself in the final playback. After all: look at the above measurements….
Thanks for your interesting articles. A common criticism of your method of measuring jitter is that it is done before the da conversion. have you seen and considered this method for jitter measurement post dac? https://pubs.aip.org/asa/jasa/article/154/1/443/2903757/Absolute-measurement-of-sampling-jitter-in-audio
There are many ways to measure jitter. I haven’t seen this one, but scanning the article I cannot see an efficient way of implementation in the workflow. But I will take a closer look later.
Very interesting! That REF 10 clock must have brought a pretty big difference with the Alpha PC as well!
Yes. It did!
Thanks for explaining the clock master vs slave concept.
Considering how incredible sensitive the clock/conversion step is in the DAC, i assume that the DAC clock is still extremely sensitive to the noise even if it serves as slave to another clock?
I mean, it feels like a theory that it will follow the master exactly (and to some extent i guess it does) but i guess in reality it is not very likely that it will be immune against the same noise in the DAC anyway (in my mind).
It sounds like it is still the last clock that matters and if that one is just a fraction out of sync with the master then i assume it is still not as good as it could be? (This is a question, not a statement and you probably already said this somewhere…)
I think you are correct.
Regarding i2s:
Are you sure about it being “asynchronous” in the sense that the DAC is the master?
So far I was convinced that with i2s connections from streamer to DAC (or DDC to DAC) the clock master is the sending device.
Anyway, great site, and great YT channel. 🙂 Cheers!
Hey Medon,
With I2S the receiving dac is master. That’s also what I said, I think?
>With I2S the receiving dac is master. That’s also what I said, I think?
… yes, and I thought “that’s wrong!”. 😉
But seems, both working modes do exist, and that’s indeed news for me. Thanks!
BTW, I do have a Denafrips DDC and DAC, which almost certainly share duties by the DDC being the clock master via i2s, and the DAC following this clock.
After a brief search I found NXP’s recently updated i2s spec here…
https://www.nxp.com/docs/en/user-manual/UM11732.pdf
… that indicated that both modes are possible.
… and via PS Audios forums this one:
https://forum.psaudio.com/t/compatible-i2s-source-devices/1336/5
–> an Google Docs spreadsheet with i2s pin configurations and most importantly, an indication which company uses which i2s clock strategy.
https://docs.google.com/spreadsheets/d/1h5PMUBkldkpt1rCnAR4ZHYGZNeCe-vwIFyKWYMZWsX0/edit?pli=1&pli=1
Regards!
Thanks!
Can someone please help elaborate what “Master” really means?
Does that mean that the clock is still actually used in the DAC, but is not leading, or is it by-past completely?
If its not leading, it still sounds like it is involved and thus also still important if it is still drifting?
The slave clock synchronizes with the master. It locks on to the time signal. All within tolerances of the slave clock crystal of course.
The clock of the master is ‘leading’. The slave follows the master. It locks on the master. That is done with a PLL (Phase locked loop). The PLL makes it possible for the slave to follow the master. But if the master has some jitter the slave will be impacted by that as well. A PLL doesnt cure jitter.
With I2S it is different. It works in a different way per I2S protocol.
I²S: The source is usually the clock master *, and the DAC follows the source’s timing. With I²S, it’s typical for the sending device (like a streamer or DDC) to act as the clock master. This means the DAC doesn’t control the timing (or clocking) of the data it receives; instead, it follows the clock provided by the source.
USB (Asynchronous): The DAC is the clock master, pulling data from the source at its own timing, which allows for better jitter control and clock stability.
Unlike I²S, which has a dedicated line for clocking, S/PDIF and AES/EBU multiplex the clock and audio data together. This combined signal means that the DAC has to extract the clock from the data stream—this isn’t perfect and can introduce a bit of jitter.
* Some high-end DACs with I²S inputs use internal reclocking or buffer circuits. These designs attempt to stabilize and “clean up” the incoming clock signal, ensuring even greater timing precision before converting digital to analog.
Hope this helps.
Very informative. Thank you.
That was a VERY intersting read! Good job as usual.
Regarding the Sbooster, have you any experience with the Sbooster Ultra mk2??
Nope… not yet.