Ian,
"The relationship between time jitter and phase jitter is just an approach, not really equal or precise."
WRONG
The matematical relationship is just perfect, but at this point I assume you have not understood that the jitter result depends on the integration bandwidth, as I have explained sevral times.
You can find a lot of literature online or you can just use the online phase noise to jitter converter tool you have already used to understand.
"My LC584ALX is equipped with a JTA jitter testing package. The jitter noise floor is just 2ps. I attached the JTA specifications for you to reference. Please don’t mislead others with wrong specifications to degrade testing equipment other than yours. Can you explain where the 7ps wrong noise floor number came from?"
I have read somewhere that the jitter floor of your oscilloscope varies from 2 to 7 ps, I don't remember where but I will search again.
Maybe 2 ps is the lower limit but it could change according to the quality of the timebase (the internal reference oscillator).
However the problem does not change, YOU CANNOT MEASURE fs clocks with a jitter floor of 2 ps.
"CCHD 957 RMS time jitter was tested directly in the time domain of 2.71ps. However the phase jitter calculated by your TimePod was 0.67ns (0.1Hz to 100KHz). By comparison with the time domain measurement, I think your TimePod phase jitter calculation result is inaccurate."
WRONG
Already demonstrated in post #6970 (third picture) and in post #6997.
Your digital oscilloscope is not capable to capture the close in noise that means jitter below the jitter floor of your tool.
I attach the pictures again, please read carefully and use the online phase noise to jitter converter tool you have already used to calculate the resulting jitter yourself (if you don't trust the picture I have attached).
AND FINALLY, please let me know why in post #6968 you have arbitrarily chosen an integration bandwidth from 0.1Hz to 100kHz from the carrier to calculate the jitter of the DRIXO oscillator, while now you are refuting the same integration bandwitdh you have previously arbitrarily chosen to be applied in order to calculate the jitter of the Crystek.
Andrea
"The relationship between time jitter and phase jitter is just an approach, not really equal or precise."
WRONG
The matematical relationship is just perfect, but at this point I assume you have not understood that the jitter result depends on the integration bandwidth, as I have explained sevral times.
You can find a lot of literature online or you can just use the online phase noise to jitter converter tool you have already used to understand.
"My LC584ALX is equipped with a JTA jitter testing package. The jitter noise floor is just 2ps. I attached the JTA specifications for you to reference. Please don’t mislead others with wrong specifications to degrade testing equipment other than yours. Can you explain where the 7ps wrong noise floor number came from?"
I have read somewhere that the jitter floor of your oscilloscope varies from 2 to 7 ps, I don't remember where but I will search again.
Maybe 2 ps is the lower limit but it could change according to the quality of the timebase (the internal reference oscillator).
However the problem does not change, YOU CANNOT MEASURE fs clocks with a jitter floor of 2 ps.
"CCHD 957 RMS time jitter was tested directly in the time domain of 2.71ps. However the phase jitter calculated by your TimePod was 0.67ns (0.1Hz to 100KHz). By comparison with the time domain measurement, I think your TimePod phase jitter calculation result is inaccurate."
WRONG
Already demonstrated in post #6970 (third picture) and in post #6997.
Your digital oscilloscope is not capable to capture the close in noise that means jitter below the jitter floor of your tool.
I attach the pictures again, please read carefully and use the online phase noise to jitter converter tool you have already used to calculate the resulting jitter yourself (if you don't trust the picture I have attached).
AND FINALLY, please let me know why in post #6968 you have arbitrarily chosen an integration bandwidth from 0.1Hz to 100kHz from the carrier to calculate the jitter of the DRIXO oscillator, while now you are refuting the same integration bandwitdh you have previously arbitrarily chosen to be applied in order to calculate the jitter of the Crystek.
Andrea
Attachments
Well, if the integration bandwidth have to start at 10kHz from the carrier, please let me know what is the purpose of this thread.
You are integrating the noise floor only, and any 30 cent oscillator has a noise floor below -150 or even -160dBc.
Just as an example the Crystek CCHD-957 is -130dBC at 100 Hz from the carrier.
And above all please let me know what is the purpose of selling a FIFO buffer.
Last edited:
Did I say anywhere 10KHz?
Point is, you insist of going down to 0.1-1Hz without any evidence that it would make any sense from a digital audio perspective. Why not 0.001Hz? (measurement time is irrelevant) Why not 10Hz?
I don't see any reason why bringing the FIFO role in this discussion. Everybody and their dog should know that a FIFO addresses, for example, a real potential problem in asynchronous USB communication, but there is no evidence that yours, or any equivalent, oscillator is required for the best digital audio performance. Other than something like "it won't harm" class of arguments, of course.
Last edited:
Just in the picture you have attached, integration bandwidth starts at 10kHz from the carrier.
I didn't insist at all, I'm not the one who has arbitrarily chosen an integration bandwidth starting from from 0.1Hz, please read carefully post #6968 and look at the first picture
Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter
And you are wrong about the FIFO, you don't need a FIFO buffer to cure the problem in asynchronous USB communication, just use a JLSounds USB to I2S converter, even with poor oscillators since you think good oscillators are not needed.
Or just use this 30 USD device
Lusya CM6631A Digitale Modulo di Interfaccia DAC Scheda USB a IIS SPDIF Uscita 24Bit 192K F3 011|Digital-to-Analog Converter| - AliExpress
I would expect more consistency from you.
I think you understand what I mean.
That's an Analog Devices illustration for the purpose of phase noise and jitter calculations. Did it say anywhere this is a digital audio example?
If not you, then who started strutting phase noise measurements starting from 0.1Hz since your oscillators are up for sale, and declaring the close in phase noise as the key to digital audio nirvana?
Could you once and for good give up these knee jerk reactions to personally insult the knowledge and experience of anybody that disagrees with you?
Hm, every finite-length fifo over/underflows when merging two clock domains. The longer (= safer) it is, the longer latency it introduces (either from the start or eventually, depending on the clock ratio and implementation).
Honestly, I do not understand why people do not use DAC clocks and a simple clock distribution buffer with internal I2C-configurable dividers and clock their SMB PCM interfaces externally (slave mode). Maybe it comes down to linux drivers which HW vendors typically try to avoid...
Absolutely, unfortunately I don't think we have a better method for joining two clock domains... For audio purposes, I believe the starting assumption is that the two clock domains are running at the same (or very close) frequency, and it's only the local variations due to the phase noise that have to be eliminated. This may or may not be true, I don't know, but I do know that the clock recovered for example after an asynchronous USB transport is, in general, not in particular of a good quality. How good or bad does it have to be, this is yet another parallel discussion. Anyway, it this case, de FIFO doesn't have to be too deep.
A discussion about sizing the FIFO memory and the trade between data streaming continuity and latency can be very contentious, I personally don't think a Mb size FIFO, to guarantee 1 hour of uninterrupted streaming when the clock domains are (...) ppm different in frequency. I don't know if there is any non official standard in the pro audio world (since I'm pretty sure there is none for the consumer level devices). In general, I'm not even sure a FIFO would practically bring much to the table anyway, as you say. Except for yet another marketing/sales differentiator, of course.
Depends of what you mean of "clock domain". "Clock domain" is the generic denomination when designing a FIFO, in the context of audio the "clock domain" definition can be much more relaxed to what I already mentioned, local variations due to the phase noise/jitter.
But then as I already said, I don't believe a FIFO for "cleaning" the audio clock is really required, other than a sales differentiator, at least until somebody proves otherwise. A FIFO for audio is ultimately as useless as a -130dBc @1Hz clock phase noise clock. But this is just me.
Correct, brain fart here. But then the original clock could too use (according to the FIFO promoters) some clean up before feeding the DAC.
Last edited:
So you dont think clock quality matters after a certain quality and the cheapest clocks are already godd enough?
Edit: clock quality meaning signal frequency stability
Edit 2: If not, sure there is a law of deminishing returns, but espeacially in Hifi the "better cant harm" is not so unreasonable for me
And for testing "If you can hear a difference" a blind abx test is really the best
Edit: clock quality meaning signal frequency stability
Edit 2: If not, sure there is a law of deminishing returns, but espeacially in Hifi the "better cant harm" is not so unreasonable for me
And for testing "If you can hear a difference" a blind abx test is really the best
Last edited:
A DIR (Digital Input Receiver) PLL would lock on the SPDIF signal preamble pattern, which is data independent. So while the biphase-mark encoded data has to be decoded anyway downstream, the recovered clock is not jitter affected in the process.
Of course, one may claim a PLL is a bad idea, however this is exactly what, for example, the ESS DACs can do internally, using the "horrible" DPLL, and I haven't heard much SQ complaints about. Of course, there's always a possibility to disable the evil ESS DPLL and do all the DIR and clock recovery externally; I have still to see a serious implementation of such an approach, using an ESS DAC.
Of course, one may claim a PLL is a bad idea, however this is exactly what, for example, the ESS DACs can do internally, using the "horrible" DPLL, and I haven't heard much SQ complaints about. Of course, there's always a possibility to disable the evil ESS DPLL and do all the DIR and clock recovery externally; I have still to see a serious implementation of such an approach, using an ESS DAC.
I think he says they are getting rid of this filter problem, in any case a very nice presentation i linked the the time to the filter audibility but I recommend the whole video RMAF 11 Noise-Shaping Sigma-Delta Based DACs, Martin Mallison, CTO, ESS Technology - YouTube
RMAF 11 Noise-Shaping Sigma-Delta Based DACs, Martin Mallison, CTO, ESS Technology - YouTubeThe original/master clock feeds the DAC directly and the async USB receiver which generates the I2S signals. Or instead of the USB receiver it feeds the I2S/PCM perfipheral of RPi through bitclock+frameclock dividers, or PCM peripheral of e.g. Rock64 which has the bitclock+frameclockdividers integrated and configurable directly by the linux hw driver. Or the DAC itself generates the I2S master signals from the master clock.
Since the master clock runs the delta/sigma conversion and determines thus the DAC performance, no reason to fifo-clean anything, the I2S signals are synchronous to the master clock.