Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter

Gentlemen,

When the time comes many of us will find out for ourselves if there is any audible difference between the various squaring circuits when used with our own dacs. In the meantime, ongoing debate serves no further useful purpose. By now the readers already know the positions of both designer viewpoints.
 
While we're on the topic, perhaps someone can help out here: I get that the shorter rise time is an advantage in terms of jitter reduction but i can't really see why overshoot should be a problem for the clock signal (as long as it's not too excessive i guess)
Greetings
Oli

In fact the problem is less than zero.

And the jitter reduction due to the rise time is limited to the noise floor, so again almost zero since we are talking about noise floor around -160 dBc.
Close in phase noise is not affected at all as we have demonstrated by the plots I have published.
 
Hello,
This shows one of the diy mc prepre amplifier swarming around in the eighties.
Back then it was a combination of big electrolityc caps, NEC 1 F supercap in combination with old fashioned sealed lead batteries. The circuit would just take a few mA.
BUT most builds back then coming from the group around Jean Hiraga paid great attention to the way the power supply was connected to the circuit.
There is no need for gold plated connectors but if you use big F supercaps because you want the lowest esr possible you cannot combine them with connector quality similar to the cheapest mobile phone charger.
Greetings,Eduard
Just solder the leads in place once you have worked out your layout and tested the circuit.
 
Disabled Account
Joined 2002
Hello Australia,
If the '' soldering area '' can be reached with little difficulty to make a good solder joint that is what i usually do.
For the wire i use the tiny Kimber cable covered with teflon, copper or silver magnet wire.
In many occasions you can at least improve the connection by soldering it on one side.
Once you know the length needed it is a piece of cake. Absolutely no need to introduce a pile of '' parts '' while two pieces of wire and a bit of solder can do the same.
Some people here ( including me) spend half of their budget for their digital gear on the power supplies and every now and then they will improve it with the latest winner but will connect it again with the same crappy connectors.
I am still waiting for my old coworker to do some metal parts for me but once that is done i will add some photos.
Greetings, eduard
P.s By the way i think Sinepi could be a real winner because like Supersurfer said the connections are better. Of course it comes with again a new improvement on the power supply. Of course number two in the contest allows you to put it real close to the sinepi. The 3000F option is just to big. A few more years and they will probably get smaller.
 
FIFO Reclock in a DSP system

Hey guys, I have a question on using Ian's FIFO reclock in a multichannel system comprising of a DSP in addition to RPi and DACs.

So if I connect RPi directly to a DSP which is doing crossover and EQ work, then send the resulting 4 channels to FIFO reclock and then to two DACs, am I getting the proper reclocking here? Additionally, the DSP is using the master clock from reclocker's XO board (via slave connection).

Should I instead connect the FIFO reclock between RPi and DSP in order to fix RPi's issues with signal clock? I don't know if these issues somehow affect the DSP or is the signal also reclocked when entering the DSP.

Maybe it's a stupid question but I'm a bit confused here. When I bought the reclock I actually thought I will be reclocking the signal twice - after RPi and after the DSP, but of course this is not even possible as the reclock only takes one LRCK/BCK and multiple data streams.
 
Hey guys, I have a question on using Ian's FIFO reclock in a multichannel system comprising of a DSP in addition to RPi and DACs.

So if I connect RPi directly to a DSP which is doing crossover and EQ work, then send the resulting 4 channels to FIFO reclock and then to two DACs, am I getting the proper reclocking here? Additionally, the DSP is using the master clock from reclocker's XO board (via slave connection).

Should I instead connect the FIFO reclock between RPi and DSP in order to fix RPi's issues with signal clock? I don't know if these issues somehow affect the DSP or is the signal also reclocked when entering the DSP.

Maybe it's a stupid question but I'm a bit confused here. When I bought the reclock I actually thought I will be reclocking the signal twice - after RPi and after the DSP, but of course this is not even possible as the reclock only takes one LRCK/BCK and multiple data streams.

Which FiFo do you use? The FiFoPi or McFiFo?
 
Hi Ian,

as I said several times you cannot measure the jitter of the Driscoll oscillator after the sine to square converter unless the resulting jitter was higher than 2 to 7 ps (the noise floor of your digital oscilloscope).
The Driscoll oscillator at 22.5792 MHz has a jitter of 76fs, almost two orders of magnitude lower than the noise floor of your tool, so you have no way to measure it.

The phase noise of the FIFO buffer output signals has already been measured and published.
The phase noise of the BCK is around -140dBc at 10 Hz from the carrier, better than the phase noise of the sine wave input from the Driscoll oscillator at 24.576 MHz.
The phase noise of the LRCK is around -100dBc at 0.1Hz from the carrier, far better than the phase noise of the sine wave input from the Driscoll oscillator at 24.576 MHz, and the noise floor is the same of the sine wave oscillator.

Evidently the problems you are pointing out do not actually exist by measurements.

Given the results we have achieved with our oscillators (maybe the best oscillators ever built for digital audio) I don't think you can teach us much about RF design and layout, this is just my opinion.
Anyway:
1. the RF signals are properly terminated by using a proper relais configuration following the basic RF rules. We are not the first using such configuration and we would thank those who did it before us.
2. No ground loop and no crosstalk by measurements with both oscilaltors installed, so the real benefits are clear. A phase noise of -100 dBc at 0.1 Hz from the carrier is state of the art result.
3. The phase noise measurements tell that the PCB design is RF optimized.

Just to point out again, we don't want to take any credit, the credits go to those we have thanked several times.
We have never claim we have invented something and we have never said we are the first using such circuits.
We are just very humble and we try to learn from those who are much more skilled than us.
Obviously we choose who to learn from.

Finally, we have designed the STS and the FSDO (with the LTC6957) for the diy audio community and to be used with your FIFOs, so if you'll get better results with your SinePi it will be good for the community.
The only issue is that your measurement will be at least two order of magnitude worse than the sine wave oscillator (at least 2 ps), since you cannot measure a jitter of 76 fs.

The sine to square converter we are designing for our SOTA audio system is totally different, much more complex and expensive.
And also the digital front-end (FIFO) we are designing for our top system is much more complex and expensive, nothing to do with the Lite series.
It will be a 3 chassis device for the FIFO only, we don't design for stacking devices.

Andrea

@andrea_mori

I respect the jobs you did for the community. But as an engineer, I really can not help to point out if there is something that obviously incorrect. I’m sorry if that makes you feel uncomfortable.

1. ”The Driscoll oscillator at 22.5792 MHz has a jitter of 76fs” That’s totally wrong
Assuming your phase noise plot measurement was correct, based on this result, the estimated RMS phase jitter will be 2.589ps for the integration bandwidth from 0.1Hz to 100KHz. 76fs was 30 times wrong! Please see the attached screenshot for how it was calculated.

Next time when you post your jitter results, please do indicate that they are phase jitter, and don’t forget to specify the integrated bandwidth.
Time jitter is a real parameter of a clock signal which can be measured directly in the time domain. Phase jitter doesn’t exist in the real world. It can just be indirectly estimated/calculated from a phase noise plot. Theoretically phase jitter can be closed to time jitter, but with conditions. You have to integrate it through the full bandwidth.

Really don’t know how you got the number 76fs. Can you explain?

2.589ps is still within LC584AXL’s time jitter measurement range though it’s very close to the jitter measurement noise floor (2ps by default). And by comparison, it can clearly tell which one is better and better by how much in RMS time jitter difference. Please do not worry at all..

2. ”Evidently the problems you are pointing out do not actually exist by measurements” It’s true for you but only because your measurement tool can not see them.

Unless you upgrade your phase noise analyzer to E5052B or the same/higher grade, you will never see the crosstalk. The reason is that your TimePod has a very narrow detection bandwidth of just 100KHz. It’s really impossible for a TimePod to see the crosstalk as long as the crosstalk phase noise spur happens above that range. That explains why you didn’t notice the cable ground introduced crosstalk issue when you designed your squarers.

Don’t tell me that only the clock close-in phase noise affects the sound quality and you don’t think the crosstalk matters. That’s only your point. Based on my real listening experiences, both phase noise floor and the time domain clock signal quality are also significant to the final sound quality, just in different ways.

3. ”The phase noise of the BCK is around -140dBc at 10 Hz from the carrier, better than the phase noise of the sine wave input from the Driscoll oscillator at 24.576 MHz.” That could be still questioning

What your TimPod measures a square wave clock is just the phase noise of the fundamental frequency components because the 27MHz LPF converts the square wave back into sine wave again before feeding into ADC. All harmonics frequency components were cut off by the LPF filter. So your TimePod may not exactly tell the real quality of a square wave, no mention the rising and falling time.

Converting a square wave back to sine wave before feeding signal into ADC, it really seems meaningless to evaluate the quality of a sine to square converter in this way.

4. ”In fact the problem is less than zero”
That sounds more like marketing words. An engineer usually doesn’t say it in this way because we know in the real world nothing is perfect. If you think the problem is less than zero it could be just because your tool can not see them.

Regards,
Ian
 

Attachments

  • DRIXO24PhaseJitter.png
    DRIXO24PhaseJitter.png
    75.9 KB · Views: 340
  • BCK from_FPGA +Reclock vs Drixo24576.png
    BCK from_FPGA +Reclock vs Drixo24576.png
    148 KB · Views: 308
Last edited:
@andrea_mori

I respect the jobs you did for the community. But as an engineer, I really can not help to point out if there is something that obviously incorrect. I’m sorry if that makes you feel uncomfortable.

1. ”The Driscoll oscillator at 22.5792 MHz has a jitter of 76fs” That’s totally wrong
Assuming your phase noise plot measurement was correct, based on this result, the estimated RMS phase jitter will be 2.589ps for the integration bandwidth from 0.1Hz to 100KHz. 76fs was 30 times wrong! Please see the attached screenshot for how it was calculated.

Next time when you post your jitter results, please do indicate that they are phase jitter, and don’t forget to specify the integrated bandwidth.
Time jitter is a real parameter of a clock signal which can be measured directly in the time domain. Phase jitter doesn’t exist in the real world. It can just be indirectly estimated/calculated from a phase noise plot. Theoretically phase jitter can be closed to time jitter, but with conditions. You have to integrate it through the full bandwidth.

Really don’t know how you got the number 76fs. Can you explain?

2.589ps is still within LC584AXL’s time jitter measurement range though it’s very close to the jitter measurement noise floor (2ps by default). And by comparison, it can clearly tell which one is better and better by how much in RMS time jitter difference. Please do not worry at all..

2. ”Evidently the problems you are pointing out do not actually exist by measurements” It’s true for you but only because your measurement tool can not see them.

Unless you upgrade your phase noise analyzer to E5052B or the same/higher grade, you will never see the crosstalk. The reason is that your TimePod has a very narrow detection bandwidth of just 100KHz. It’s really impossible for a TimePod to see the crosstalk as long as the crosstalk phase noise spur happens above that range. That explains why you didn’t notice the cable ground introduced crosstalk issue when you designed your squarers.

Don’t tell me that only the clock close-in phase noise affects the sound quality and you don’t think the crosstalk matters. That’s only your point. Based on my real listening experiences, both phase noise floor and the time domain clock signal quality are also significant to the final sound quality, just in different ways.

3. ”The phase noise of the BCK is around -140dBc at 10 Hz from the carrier, better than the phase noise of the sine wave input from the Driscoll oscillator at 24.576 MHz.” That could be still questioning

What your TimPod measures a square wave clock is just the phase noise of the fundamental frequency components because the 27MHz LPF converts the square wave back into sine wave again before feeding into ADC. All harmonics frequency components were cut off by the LPF filter. So your TimePod may not exactly tell the real quality of a square wave, no mention the rising and falling time.

Converting a square wave back to sine wave before feeding signal into ADC, it really seems meaningless to evaluate the quality of a sine to square converter in this way.

4. ”In fact the problem is less than zero”
That sounds more like marketing words. An engineer usually doesn’t say it in this way because we know in the real world nothing is perfect. If you think the problem is less than zero it could be just because your tool can not see them.

Regards,
Ian

Ian,

at this point I don't understand if your RF skills are very limited or if you are throwing nonsense calculations in order to confuse those who are reading.
I hope the second, otherwise you should restart from scratch.

BTW, assuming the second ipothesys some clarifications are needed.

It's quite curious that now you are pointing to an integration bandwidth from 0.1Hz to 100KHz to calculate the RMS jitter.
I wonder if you understand what this means, I wonder if you understand what tools you need to measure the phase noise so close to the carrier.
I wonder if you know the basis of the cross correlation, I'm not sure.

I'm pretty sure you have not yet understood that when the phase noise has reached the noise floor the plot becomes flat.
At such frequencies like 22/24 MHz the noise floor is reached in the range 1kHz-10kHz so the 100kHz integration bandwidth upper limit is more than enough.

And since you wrote "The phase noise of the BCK is around -140dBc at 10 Hz from the carrier, better than the phase noise of the sine wave input from the Driscoll oscillator at 24.576 MHz. That could be still questioning", I'm sorry to say I have to assume you have not understood how frequency division affects the phase noise.
I would suggest rubiola.org and time-nuts to learn a little.

So, since the jitter is mainly affected by the close in noise, do you think your digital oscilloscope with its poor time base and without cross correlation was able to measure phase noise/jitter at 1 Hz or even 0.1 Hz from the carrier?

The answer is NO, let me explain why.

First picture
The RMS jitter of the DRIXO oscillator at 22.5792 MHz calculated with an integration bandwidth 1Hz to 100kHz is 76fs, no doubt from the upper image.
The RMS jitter of the DRIXO oscillator at 22.5792 MHz calculated with an integration bandwidth 0.1Hz to 100kHz is 980fs (lower image).
It was pretty obvious since the jitter is mainly affected by the close in noise.
Although the jitter noise floor of your digital oscilloscope (2 to 7 ps) is far worse than the DUT you would measure (980fs), there is no way your tool could measure with such integration bandwidth lower limit (0.1 Hz) because its time base is much worse than the DUT and moreover the cross correlation is the only way to reach such lower limit (and your tool does not use cross correlation).
Let me demonstrate the reason.

Second picture
Using an integration bandwidth from 0.1Hz to 100kHz the RMS jitter of the Crystek CCHD-957 is 0.67 ns, while you have measured 2.71 ps with your digital oscilloscope.
This demonstrates that your tool is not able to measure the close in jitter, it substantially measures the noise floor but it's not capable of measuring the close in noise.
It's suitable for telecommunication mesurements but not to measure the close in jitter and it's quite obviuos due to its poor time base.

Third picture
By calculating the RMS jitter of the Crystek CCHD-957 starting from the phase noise plot of its datasheet, the resulting jitter is almost the same measured by the Timepod when using 0.1 Hz to 100 kHz integration bandwidth.
The lower image clearly shows a calculated jitter of 0.47 ns, a little better than the one measured by the Timepod (0.67 ns), maybe the specific DUT has a little worse noise floor.

Anyway the resulting RMS jitter is very similar, 0.67 ns vs 0.47 ns, while you have measured 2.71 ps, more than 2 orders of magnitude better than the real jitter.

I hope it's clear you have no way to measure such close in jitter with your digital oscilloscope, the time base of your tool is much worse than the DUT you would measure.
It's phisically impossible.

Andrea
 

Attachments

  • DRIXO 225792 MHz Jitter.png
    DRIXO 225792 MHz Jitter.png
    227.1 KB · Views: 275
  • Crystek_24576MHz Jitter.png
    Crystek_24576MHz Jitter.png
    202.1 KB · Views: 270
  • Crystek_CCHD957_Calculated Jitter 01-100kHz.jpg
    Crystek_CCHD957_Calculated Jitter 01-100kHz.jpg
    455.7 KB · Views: 263
Last edited:
If ground noise when two clock grounds are connected at one time is an audible problem for a particular dac, it should be easy enough to find out. Just connect one clock at a time and do listening tests, then connect both clocks and do listening tests again. Repeat a few times to check for consistency. Using very familiar music may make it easier to spot differences. If someone can't hear a difference with their dac then its not a practical issue for them. If the dac is later installed in a more resolving system, maybe try the test again at that time.
 
If ground noise when two clock grounds are connected at one time is an audible problem for a particular dac, it should be easy enough to find out. Just connect one clock at a time and do listening tests, then connect both clocks and do listening tests again. Repeat a few times to check for consistency. Using very familiar music may make it easier to spot differences. If someone can't hear a difference with their dac then its not a practical issue for them. If the dac is later installed in a more resolving system, maybe try the test again at that time.

Right, but the assumption that the problem exists is wrong, in fact the problem does not exist.

There is solid literature on the ideal configuration for switching two clocks using relays.
There isn't much to come up with, just follow the basic RF rules using a pair of relais with proper configuration and termination.
 
May I ask you guys why are you stopping the integration for calculating the jitter at 100KHz?

Usually, the integration upper limit is twice the carrier frequency (see the AD reference https://www.analog.com/media/en/training-seminars/tutorials/mt-008.pdf ). As such, it will lead to a wideband phase noise contribution larger than you are currently estimating, and the jitter contribution of the close in phase noise may decrease.

This would significantly affect the jitter results for the sine to square conversion process; the process significantly affects the broadband phase noise (something that indeed the timepod has difficulties measuring, due to the limited input bandwidth) and to a much lesser degree the close in phase noise (I’ve already posted in another thread two authoritative references about). As such, limiting the phase noise integration upper limit to 100KHz will always show a small jitter increase due to the conversion, since the close in phase noise contribution is overestimated.

There is also a legitimate question why are you taking the lower integration limit at 1Hz; since the phase noise increases much like the 1/f^n noise in the analog domain (where everything on top of 1/f noise is called “excess noise”) integrating down to 0.001Hz will show a much larger jitter contribution of the close in phase noise.
 
Last edited:
If ground noise when two clock grounds are connected at one time is an audible problem for a particular dac, it should be easy enough to find out. Just connect one clock at a time and do listening tests, then connect both clocks and do listening tests again. Repeat a few times to check for consistency. Using very familiar music may make it easier to spot differences. If someone can't hear a difference with their dac then its not a practical issue for them. If the dac is later installed in a more resolving system, maybe try the test again at that time.

:up: Upvote :up:

Reason I am now working on my own solution to have the clocks in their own chassis on top of the DAC, selecting the sine clock and the 1x 2x 4x doubler/multiplayer based on reading actual FS directly from the Raspberry PI and automatically switch the right constellation with RF relays. Not sharing relays or grounds….

So only one sine signal will arrive at the Fifopi to be squared….
 
And this is your technical contribution to the discussion?
Really constructive.

I understand you don't want to miss an opportunity to attack me, but at least write something meaningful.
Try the ignore function.

If ground noise when two clock grounds are connected at one time is an audible problem for a particular dac, it should be easy enough to find out. Just connect one clock at a time and do listening tests, then connect both clocks and do listening tests again. Repeat a few times to check for consistency. Using very familiar music may make it easier to spot differences. If someone can't hear a difference with their dac then its not a practical issue for them. If the dac is later installed in a more resolving system, maybe try the test again at that time.
Such listening comparison is useless without quick switching to compensate for our short aural memory span no matter how resolving the system is.
 
May I ask you guys why are you stopping the integration for calculating the jitter at 100KHz?

Usually, the integration upper limit is twice the carrier frequency (see the AD reference https://www.analog.com/media/en/training-seminars/tutorials/mt-008.pdf ). As such, it will lead to a wideband phase noise contribution larger than you are currently estimating, and the jitter contribution of the close in phase noise may decrease.

This would significantly affect the jitter results for the sine to square conversion process; the process significantly affects the broadband phase noise (something that indeed the timepod has difficulties measuring, due to the limited input bandwidth) and to a much lesser degree the close in phase noise (I’ve already posted in another thread two authoritative references about). As such, limiting the phase noise integration upper limit to 100KHz will always show a small jitter increase due to the conversion, since the close in phase noise contribution is overestimated.

There is also a legitimate question why are you taking the lower integration limit at 1Hz; since the phase noise increases much like the 1/f^n noise in the analog domain (where everything on top of 1/f noise is called “excess noise”) integrating down to 0.001Hz will show a much larger jitter contribution of the close in phase noise.

Because when the noise floor is reached the plot becomes flat.
For oscillators in the 20MHz range the noise floor is reached form 1kHz to 10 kHz from the carrier.
Even a poor oscillator like the Crystek CCHD-957 reaches the noise floor at 10 kHz from the carrier as clearly showed in the datasheet.
It has been measured by the E5052A and the baseband was 10Hz to 1MHz from the carrier, and not twice the frequency of the carrier which would be around 50MHz.

The R&S FSWP can measure up to 50GHz but its baseband noise measurements does not reach twice the carrier frequency (100GHz!), its baseband is limited to 30MHz.
Of course the baseband upper limit of the FSWP (30MHz) is higher than the one of the Timepod (100kHz), but you should know the reason: the frequency limit of the Timepod is 30MHz and at such frequencies the noise floor is reached far below of its baseband upper limit of 100kHz, while the FSWP can measure 50GHz oscillators and at such high frequencies the noise floor is reached at higher distance from the carrier than 100kHz.

The broadband phase noise does not affect much the jitter, the jitter is mainly affected by the close in phase noise as demonstrated shifting the integration bandwidth lower limit from 1Hz to 0.1Hz in a previous post.
The RMS jitter of the DRIXO oscillator at 22.5792 MHz calculated with an integration bandwidth 1Hz to 100kHz is 76fs, while the RMS jitter of the same oscillator calculated with an integration bandwidth 0.1Hz to 100kHz is 980fs (lower image).

Moreover the 300000 Euro FSWP phase noise analyzer has the same LPF input filter of the Timepod around 30 MHz as clearly showed in the datasheet, indeed its baseband upper limit is exactly 30MHz.
You should know that the FSWP uses down conversion to measure up to 50GHz, no instruments can measure directly 50GHz and even much lower frequencies.

It's quite obvious that moving the integration bandwidth to lower frequencies such 0.001 Hz the jitter increases dramatically, but you should know that to measure down to 0.1Hz from the carrier the cross correlation takes several hours to do the job (8 and more).
So what would be the benefit?

We are talking about measurements comparison between a phase noise analyzer and a digital oscilloscope which cannot measure at such close in frequencies to the carrier Since it has a poor time base and does not use cross correlation.

It would be a wast of time since the digital oscilloscope measurements limit it's very clear from the picture I have posted: using an integration bandwidth from 0.1Hz to 100kHz the RMS jitter of the Crystek CCHD-957 is 0.67 ns, while the digital oscilloscope has measured 2.71 ps, more than 2 orders of magnitude better than the real jitter.
Again quite obvious since the jitter floor of the digital oscilloscope is 2 to 7 ps.
 
Last edited: