Hi,
Firstly from where does jitter come? The I2S hardware in any DSP is (derived) divided by the main system crystal, while reading allo kali reclocker, they claim the source of jitter is system crystal. I beg to differ, the crystal clock is already divided to generate I2S which essentially means several crystal clock pulses (allegedly jittery) are consumed to produce a single I2S clock, the jitter is well absorbed by these several clocks, if I2S were to really be affected by the main crystal jitter then only the main clock's last pulse jitter will reflect in I2S which isn't really much. Is the entire Kali reclocker a gimmick?
Kali reclocker is paired with Piano DAC 2.1 which uses PCM5142 which has a better jitter control than HiFiberry DAC8x. Does it mean that the former is far superior due to its own jitter better control and the alleged improvement from kali reclocker?
Thanks and Regards,
WonderfulAudio
Firstly from where does jitter come? The I2S hardware in any DSP is (derived) divided by the main system crystal, while reading allo kali reclocker, they claim the source of jitter is system crystal. I beg to differ, the crystal clock is already divided to generate I2S which essentially means several crystal clock pulses (allegedly jittery) are consumed to produce a single I2S clock, the jitter is well absorbed by these several clocks, if I2S were to really be affected by the main crystal jitter then only the main clock's last pulse jitter will reflect in I2S which isn't really much. Is the entire Kali reclocker a gimmick?
Kali reclocker is paired with Piano DAC 2.1 which uses PCM5142 which has a better jitter control than HiFiberry DAC8x. Does it mean that the former is far superior due to its own jitter better control and the alleged improvement from kali reclocker?
Thanks and Regards,
WonderfulAudio
It comes from very basic physics. Its a type of noise, but noise in the durationi analog time intervals rather than noise in amplitude.
In some cases jitter originates in crystal oscillators used in DACs and or in ADCs. Jitter can then be made worse by various physical processes, such as passage of a clock signal through a dac.
Jitter is the time domain name for errors (noise) in the duration of time intervals (i.e. unwanted variations in time clock accuracy). Time jitter can also be described in the frequency domain where it is referred to as phase noise. Phase noise (PN) is distinguished from amplitude noise (AN). That is to say, they are two different and orthogonal types of noise.
Probably not. There are application notes on time jitter and its effects on dacs published by various companies and in some scientific papers. Analog Devices is one company that has published application notes on jitter and phase noise in digital audio clocks and the resulting effects on data conversion.
Far superior? Is a very low noise phono preamp "far superior" to a somewhat higher noise phono preamp? "Far superior" is a vague description, not a measurement of some difference in a type of noise.
@wonderfulaudio : I will not discuss jitter, but just for comparison:
The proposed chain:
player -> in-memory DMA buffer -> RPi I2S transmitter in master mode clocked by very jittery clock generated by fractional division from non-audio-frequency PLL'd clock -> long FIFO in the Kali reclocker adding variable latency (initially 0.7s specced by the vendor) and eventually unavoidable buffer issues -> I2S master (bitclock, frameclock) clocked by precise master clock chip in the Kali reclocker -> I2S slave in PCM5142 -> master clock generated by internal DAC PLL from I2S bitclock -> the actual DA conversion clocked by the PLL'd master clock
Vs. the IMO logical chain:
player -> in-memory DMA buffer -> RPi I2S transmitter in slave mode clocked by incoming bit/frameclocks -> I2S master in PCM5142, bit/frame clocks generated by PCM5142 itself from precise master clock chip -> the actual DA conversion clocked by the precise master clock
No need for any reclocker with dumb plain FIFO which will always over/underrun after some time and add a major latency. No need for jittery regeneration of the MCLK by the DAC. Plus there already is a MCLK in the reclocker, but the DACs do not use it because the RPi pinheader does not have a dedicated pin for MCLK and the reclocker could not be just inserted onto the pinheader between the DAC and RPi, damaging sales of the extra (IMO technically incorrect and unnecessary) board...
The proposed chain:
player -> in-memory DMA buffer -> RPi I2S transmitter in master mode clocked by very jittery clock generated by fractional division from non-audio-frequency PLL'd clock -> long FIFO in the Kali reclocker adding variable latency (initially 0.7s specced by the vendor) and eventually unavoidable buffer issues -> I2S master (bitclock, frameclock) clocked by precise master clock chip in the Kali reclocker -> I2S slave in PCM5142 -> master clock generated by internal DAC PLL from I2S bitclock -> the actual DA conversion clocked by the PLL'd master clock
Vs. the IMO logical chain:
player -> in-memory DMA buffer -> RPi I2S transmitter in slave mode clocked by incoming bit/frameclocks -> I2S master in PCM5142, bit/frame clocks generated by PCM5142 itself from precise master clock chip -> the actual DA conversion clocked by the precise master clock
No need for any reclocker with dumb plain FIFO which will always over/underrun after some time and add a major latency. No need for jittery regeneration of the MCLK by the DAC. Plus there already is a MCLK in the reclocker, but the DACs do not use it because the RPi pinheader does not have a dedicated pin for MCLK and the reclocker could not be just inserted onto the pinheader between the DAC and RPi, damaging sales of the extra (IMO technically incorrect and unnecessary) board...
Last edited:
I already post something about jitter, years ago.
What I understood, please correct me if I am wrong:
let's imagine a DAC that transform digital signal to analog signal at a dedicated frequency and resolution. Let say 44.1 khz / 16bits
Because your input signal is digital the supplier is digital too, that means it works at a dedicated digital frequency let say 100mhz (you can choose 4GHZ if you want).
typing 100 000 000 / 44100 is not an integer. That means sometime the reading is delayed to the next clock signal.
Then for the DAC the 'new' analog output may be slightly delayed. It depends of the DAC algorithm but it can be worth if it occurs on a last data bit.
Morever, if the supplier is working in slave mode, the transfert rate may not be constant as it depends of the interrupt system on the supplier chip, its own interrupt clock rate, the priority of the interrupt, and the code used to transfert data from memory to pins.
that said, for a chip like raspberry I am not sure I2S is a better way than USB2 : to make it simple, at the end it is the same mechanism, with the same drawbacks even if the programs to manage USB devices are more complexes.
Please note that the 2 first raspberrys are the worst in term of constant flow rate as there was only 1 data bus shared between network, usb and i2s. It means it was not possible to handle at the same time network and i2s for example. Things changed since.
This is why a buffer between the supplier and the DAC can help to improve the 'constantness' of the analog signal from the DAC . The goal is to work asynchronly. There are 2 programs that work in an independant way: a program that manage buffer->DAC at DAC speed to make the analog signal constant. And the second program is working at the supplier speed (that can not be very constant) . That means the buffer size may be very important (it depends of the supplier) to counterbalance delays.
This is what I understood on jitter and why it is difficult to measure.
What I understood, please correct me if I am wrong:
let's imagine a DAC that transform digital signal to analog signal at a dedicated frequency and resolution. Let say 44.1 khz / 16bits
Because your input signal is digital the supplier is digital too, that means it works at a dedicated digital frequency let say 100mhz (you can choose 4GHZ if you want).
typing 100 000 000 / 44100 is not an integer. That means sometime the reading is delayed to the next clock signal.
Then for the DAC the 'new' analog output may be slightly delayed. It depends of the DAC algorithm but it can be worth if it occurs on a last data bit.
Morever, if the supplier is working in slave mode, the transfert rate may not be constant as it depends of the interrupt system on the supplier chip, its own interrupt clock rate, the priority of the interrupt, and the code used to transfert data from memory to pins.
that said, for a chip like raspberry I am not sure I2S is a better way than USB2 : to make it simple, at the end it is the same mechanism, with the same drawbacks even if the programs to manage USB devices are more complexes.
Please note that the 2 first raspberrys are the worst in term of constant flow rate as there was only 1 data bus shared between network, usb and i2s. It means it was not possible to handle at the same time network and i2s for example. Things changed since.
This is why a buffer between the supplier and the DAC can help to improve the 'constantness' of the analog signal from the DAC . The goal is to work asynchronly. There are 2 programs that work in an independant way: a program that manage buffer->DAC at DAC speed to make the analog signal constant. And the second program is working at the supplier speed (that can not be very constant) . That means the buffer size may be very important (it depends of the supplier) to counterbalance delays.
This is what I understood on jitter and why it is difficult to measure.
There is more that one source of jitter, and more than one way to measure jitter and or phase noise. What is hard to do is to measure jitter which is close-in to the clock's nominal frequency. Small deviations in clock frequency may be considered as drift or wander, rather than as jitter. At what point clock frequency deviation becomes considered to be jitter is probably more easily discussed in the frequency domain view where we talk in terms of "phase noise."
Searching for "clock jitter measurement," and or "clock phase noise measurement," should turn up quite a bit of technical literature.
Searching for "clock jitter measurement," and or "clock phase noise measurement," should turn up quite a bit of technical literature.