Hi Jan,
yes, the FPGA produces noise, every Processor does, not as bad as the SOC on the raspberry, but still.
(btw, the RPI is way better at this than a normal PC)
maybe the J2 has bit less jitter than the u.fl/J7 output but you pay for it with alot more noise.
and when you seperate the RPI from the FifoPi you only get rid of RFI/EMI and not the noise on the signal.
and when you do seperate these two, make the cables as short as possible and use U.fl, if i remember correctly
the I2S protocoll allows not more than 10cm trace length on the PCB, it is not ment to go over cables.
Idk if it is beneficial to use ian´s IsolatorPi when you already have a fifoPi.
and, why spend at least 100 bucks for the isolatorPI (...it needs an additional decent PSU) when the FofoPi
has an Isolator build in ?
and lastly, why do you have to modify your DAC, when you edo istening tests on the fifoPi ??
cheerio,
Balou
It looks like you don't get the point, I did post a plot to explain that the jitter measurement could be useless.
I don't want to discuss the phase noise measurement of the XO, there is already another thread, I would discuss the efficiency of the FIFO.
I have published a plot related to XO measurement because until now I have not yet measured the FIFO, simply to explain that the jitter measurement does not show the spectrum of the noise, so you can draw wrong conclusion.
As you can see from the plot, the Timepod measures the jitter as the standard for telecommunication, with an integration bandwidth from 300Hz up to 3kHz (dashed blu lines), that's useless for digital to analog conversion.
Indeed if you look at the jitter results only the Crystek is far superior against the other 2 oscillators, but if you look at the phase noise plot you see clearly that the Crystek is the worst performer.
You have claimed that the Pulsar Clock is better than the Crystek, but if you measure its jitter with a standard telecommunication integration bandwidth 300 Hz to 3 kHz the Crystek will show a lower jitter.
And why?
Simply because the jitter measurement with an integration bandwidth 300 Hz to 3kHz is heavily affected from the noise floor, where the Crystek performs better than the Pulsar Clock.
This is the reason why you can calculate the jitter starting from the phase noise while you cannot do the opposite, simply because the jitter does not explain the noise spectrum, it's a stand alone number useful in telecommunication but useless in digital audio.
If you don't trust me, please do a jitter measurement of the Crystek and the Pulsar oscillators with your oscilloscope and let us know the results.
Then, if the jitter of the Crystek will result less than the jitter of the Pulsar Clock, please explain why the Pulsar Clock sounds better.
I would do this myself with the Timepod but I don't own the Pulsar Clock.
Finally, I agree with you that the jitter and phase noise are different concepts but they describe the same thing, but the phase noise measurement helps a lot to understand the spectrum of the noise, while the jitter measurement, as a stand alone number bandwidth dependent, could lead to wrong conclusion, even opposite.
In digital audio we care much about short term stability, the close in noise, so the noise floor is useless, since it's laid at the opposite side of the bandwidth.
Last edited:
Hello,
I had a little time now to see how the MCLK signal is routed on the FiFoPi.
It seems to me, that the Master clock signal is first sent through a low additive jitter, fan out buffer. One output is routed through the isolator to go into the FiFo circuit. One drives the Flip Flop and one is for output.
The FiFo and RAM get it’s power from the Raspberry pi (or J3), right?
I do understand this circuit, in case you want the same MCK for feeding your DAC. Ian build his whole system with dac around this FiFoPi and I think it’s a great idea!
But for everyone using soekris dam1021 DACs it is probably not the best option.
And I would say also for other DACs it’s not the best option but, a two (or then 4) clock system is in practical.
My problem here is, that the Master clock is isolated before it enters the FiFo so there goes the most potential out the window. The only point in this FiFo system to isolate with no downside, is between raspberry Pi and FiFo. Every jitter introduced here by the isolator, is washed away in the FiFo. But ( because 3 seperate power supply’s are not practical) there is only isolation after the FiFo. Would the ICs from FiFo and RAM mess with the clock if they weren’t isolated to it?
Well maybe I should check Ian’s classic FiFo again weather the design better suits my system.
Someone else here using the FiFoPi with a dam1021 and made some comparisons in different connection or between Ian’s classic FiFo and the FiFoPi?
I had a little time now to see how the MCLK signal is routed on the FiFoPi.
It seems to me, that the Master clock signal is first sent through a low additive jitter, fan out buffer. One output is routed through the isolator to go into the FiFo circuit. One drives the Flip Flop and one is for output.
The FiFo and RAM get it’s power from the Raspberry pi (or J3), right?
I do understand this circuit, in case you want the same MCK for feeding your DAC. Ian build his whole system with dac around this FiFoPi and I think it’s a great idea!
But for everyone using soekris dam1021 DACs it is probably not the best option.
And I would say also for other DACs it’s not the best option but, a two (or then 4) clock system is in practical.
My problem here is, that the Master clock is isolated before it enters the FiFo so there goes the most potential out the window. The only point in this FiFo system to isolate with no downside, is between raspberry Pi and FiFo. Every jitter introduced here by the isolator, is washed away in the FiFo. But ( because 3 seperate power supply’s are not practical) there is only isolation after the FiFo. Would the ICs from FiFo and RAM mess with the clock if they weren’t isolated to it?
Well maybe I should check Ian’s classic FiFo again weather the design better suits my system.
Someone else here using the FiFoPi with a dam1021 and made some comparisons in different connection or between Ian’s classic FiFo and the FiFoPi?
@ janho12345
That's correct. XOs on the FifoPi are masters. FIFO FPGA runs in slave mode. FIFO FPGA slaves (but in isolated) to the XOs making the input I2S/DSD signals synchronized to the MCLK. Un-isolated FifoPi I2S/DSD output signals go directly to non-isolated GPIO J2. Isolated FifoPi I2S/DSD output signals go to isolated GPIO J7 and u.fl connectors. Both isolated and non-isolated I2S/DSD outputs are being re-clocked right before output to eliminate additive jitter of isolators or FPGA.
All outputs are independent with their own re-clock drivers. For example, SCK on J3 and SCK u.fl output are the same signal but they are from different re-clock drivers, and with different impedance matching networks.
Good weekend.
Ian
That's correct. XOs on the FifoPi are masters. FIFO FPGA runs in slave mode. FIFO FPGA slaves (but in isolated) to the XOs making the input I2S/DSD signals synchronized to the MCLK. Un-isolated FifoPi I2S/DSD output signals go directly to non-isolated GPIO J2. Isolated FifoPi I2S/DSD output signals go to isolated GPIO J7 and u.fl connectors. Both isolated and non-isolated I2S/DSD outputs are being re-clocked right before output to eliminate additive jitter of isolators or FPGA.
All outputs are independent with their own re-clock drivers. For example, SCK on J3 and SCK u.fl output are the same signal but they are from different re-clock drivers, and with different impedance matching networks.
Good weekend.
Ian
@andrea_mori
The most significant feature of a FifoPi is to remove all the jitter from input I2S/DSD signals and then to output the same signals but replacing them with the jitter signature from the new XOs on FifoPi. FifoPi is implemented in an architecture that can remove all input jitter, but the final jitter is not decided by a FifiPi, it's decided by the XOs on the FifoPi.
Different XO sounds differently. so it would be a really interesting experience tying different XOs with FifoPi to improve sound quality according to personal preference. That's why a FifoPi is really fun. I would also be very interested in buying your XOs to get them compared with my Pulsar, CCHD957 and many others to figure out if it is my taste, I can post my result if you are interested.
If you don't mind, just let me express it one more time, though they have the same target, but jitter measurement and phase noise measurement are suitable for different applications. Jitter measurement is more suitable for digital signals such as I2S/DSD because the signal frequency is not constant (phase noise plot will be not determined). While phase noise measurement is more suitable for XO oscillators because the frequency is fixed (phase noise plot is determined and with higher accuracy). So for XO oscillators, normally people don't use jitter measurement, phase noise measurement would be the correct way to go. I didn't see your point is different from mine.
What I'm doing right now is to measure the jitter at both input and output of a FifoPi just to confirm how much improvement that a FifoPi can make. I'll continue the test and post my result. I'm not worried about the accuracy of my LC584ALX, it's more than enough to tell how much is improving.
I never question about using phase noise for XO oscillator measurement. I'm questioning if phase noise is suitable for measuring the I2S/DSD signal which the frequencies are not fixed. Few people did an I2S/DSD signal test by phase noise measurement (I could be wrong but I have neve seen one). That's why I'm curious about your phase noise testing result. I've already started posting my jitter testing result, but I never see your real related phase noise testing result be posted so far. If I can review your testing result, I'll figure out if your phase noise measure result can be trusted or can not be trusted for measuring I2S/DSD signals.
"It looks like you don't get the point, I did post a plot to explain that the jitter measurement could be useless. "
At the beginning, you mixed up the concept of jitter and phase noise, and now you say jitter measurement could be useless. I would suggest you google and go deep into the principle of signal integrity to figure out if jitter analysis is useful or useless in high speed design. I usually don't discuss technical issues in this way. It's not only unreasonable but also a bit arbitrary. I really can not get this point of yours. Just hope you can focus on the FifoPi test as you confirmed.
Regards,
Ian
Ian,
I have explained several times the reasons, every time supported by examples. A standard jitter measurement (300 Hz to 3kHz) is useful in high speed telecommunication but is useless in audio, because the integration bandwidth is not suitable for digital to analog conversion.
In such that measurement the upper limit of the bandwidth weights much more than the lower limit, simply because you get much more samples at 3kHz rather than at 300Hz.
This way you are measuring the noise floor or the broadband noise, not the close in noise that is crucial for digital audio. Close in noise means short term stability, that's exactly what we are looking for in digital audio.
Do you agree? Or do you think that we are looking for the broadband noise?
Keep in mind that if you think we are more interested in broadband noise the Crystek oscillator is far superior to the Pulsar clock, so, as I have already asked you, you should explain the reason you prefer the worst oscillator.
That said, you claimed that FifoPI performance is XOs dependent, so the better the XO the higher the performance of the FifoPi removing the jitter.
Firstly, can you please elaborate what do you mean "better XO"?
Are we talking about your subjective impression or your statements are based on technical reasons and measurements?
Let assume you are referring to technical reason and measurements of the XOs, we cannot question your subjective impressions.
So, how do you think to explain the relation between the quality of the XOs and the efficiency of the FifoPi removing the jitter?
In other words, how do you think to compare the phase noise of the XOs with the jitter of the FifoPi I2S output?
I can't figure it out, while is just obvious that we can compare the phase noise of the XOs with the phase noise of the FifoPi output.
Moreover, you have published the jitter measurement of the RPI bit clock, can you elaborate what does "679 ps" mean?
How do you read this value without the spectrum of the noise?
What does it explain to the owner of the RPI?
Finally, when you wrote "but I never see your real related phase noise testing result be posted so far", please take a look at this post
Develop ultra capacitor power supply and LiFePO4 battery power supply
I don't own your setup, so I did ask you to send me your stuff to be measured but I'm still waiting for your reply.
Andrea
I have explained several times the reasons, every time supported by examples. A standard jitter measurement (300 Hz to 3kHz) is useful in high speed telecommunication but is useless in audio, because the integration bandwidth is not suitable for digital to analog conversion.
In such that measurement the upper limit of the bandwidth weights much more than the lower limit, simply because you get much more samples at 3kHz rather than at 300Hz.
This way you are measuring the noise floor or the broadband noise, not the close in noise that is crucial for digital audio. Close in noise means short term stability, that's exactly what we are looking for in digital audio.
Do you agree? Or do you think that we are looking for the broadband noise?
Keep in mind that if you think we are more interested in broadband noise the Crystek oscillator is far superior to the Pulsar clock, so, as I have already asked you, you should explain the reason you prefer the worst oscillator.
That said, you claimed that FifoPI performance is XOs dependent, so the better the XO the higher the performance of the FifoPi removing the jitter.
Firstly, can you please elaborate what do you mean "better XO"?
Are we talking about your subjective impression or your statements are based on technical reasons and measurements?
Let assume you are referring to technical reason and measurements of the XOs, we cannot question your subjective impressions.
So, how do you think to explain the relation between the quality of the XOs and the efficiency of the FifoPi removing the jitter?
In other words, how do you think to compare the phase noise of the XOs with the jitter of the FifoPi I2S output?
I can't figure it out, while is just obvious that we can compare the phase noise of the XOs with the phase noise of the FifoPi output.
Moreover, you have published the jitter measurement of the RPI bit clock, can you elaborate what does "679 ps" mean?
How do you read this value without the spectrum of the noise?
What does it explain to the owner of the RPI?
Finally, when you wrote "but I never see your real related phase noise testing result be posted so far", please take a look at this post
Develop ultra capacitor power supply and LiFePO4 battery power supply
I don't own your setup, so I did ask you to send me your stuff to be measured but I'm still waiting for your reply.
Andrea
Ian,
just dump the endless discussion on phase / jitter
- your FiFoPi sounds very nice and that is what counts.on the subject above, yes, that would give us some very nice view and perspective on things. Looking forward to this.
just saying, as you go, please measure jitter for:
clock from PI
clock From J2
clock from U/FL
Could you do both MCK AND please also SCK !! (this does the conversion in many (or most) DAC chips...
thanks,
Doede
Anyway, one will stay prudent about jitter claims : all the experiments I made with front ends before Ian fifos always showed very clear changes in sound . So it's not as simple as : isolator, fifo, new clock, make proof what is injected before in the "front-front end" !
powersupllys decoupling and reg tipologys still change the sound, LiFePo4 are not a paragon for the good sound, etc. And the Rpi stays problematic, streamind DO stay a problem as noticed ECDESIGNS and some before him in others forums with usb sticks or sd card sources...
More and more thinking compact dac chip and old pcm ones is the best trade off ever to discrete and new fast akm/ESS. TDA1541A and AD1862...pcm46...
powersupllys decoupling and reg tipologys still change the sound, LiFePo4 are not a paragon for the good sound, etc. And the Rpi stays problematic, streamind DO stay a problem as noticed ECDESIGNS and some before him in others forums with usb sticks or sd card sources...
More and more thinking compact dac chip and old pcm ones is the best trade off ever to discrete and new fast akm/ESS. TDA1541A and AD1862...pcm46...
After reclocking the jitter should be more or less the jitter of the XO. Any decent XO has, according to the data sheets, jitter in the sub ps range (regardless of 'the bandwidth' ... which it a huge improvement over the 600ps-ish jitter of the Pi, regardless of 'the bandwidth').
From my own measurements (a few ps jitter) I experienced that it is hard to get near the specified jitter noise floor of the scope. But as changes in measurement setup brought improvements. This indicates this difference from the specs is not due to the jitter of the reclocker.
Thus, if there is no implementation flaw in the reclocker, measurement with a scope, after reclocking, will only show the limits of the scope and measurement setup.
From my own measurements (a few ps jitter) I experienced that it is hard to get near the specified jitter noise floor of the scope. But as changes in measurement setup brought improvements. This indicates this difference from the specs is not due to the jitter of the reclocker.
Thus, if there is no implementation flaw in the reclocker, measurement with a scope, after reclocking, will only show the limits of the scope and measurement setup.
I definitely acknowledge that nobody is interested in technical discussions in this thread, so I stop immediately the "endless discussion on phase/jitter".
I'm sorry to have bothered you with my technical arguments, but since I'm not interested on a factional battle I leave this thread (I will only send my measurements to the kind member that had sent my the stuff to be measured).
... diyiggy,
you have just pointed out the question to be explained by the designer, if ever someone was interested:
"all the experiments I made with front ends before Ian fifos always showed very clear changes in sound"
Why?
Have a good time
Andrea
I'm sorry to have bothered you with my technical arguments, but since I'm not interested on a factional battle I leave this thread (I will only send my measurements to the kind member that had sent my the stuff to be measured).
... diyiggy,
you have just pointed out the question to be explained by the designer, if ever someone was interested:
"all the experiments I made with front ends before Ian fifos always showed very clear changes in sound"
Why?
Have a good time
Andrea
HI Guys,
need a little help in understanding the Ian Canada architecture please.
How to adapt an RPI with these devices to output I2S to Buffalo II (and eventually BIII)?
PC Roon server RJ45 to RPI running RopieeXL with USB out to Wave I/O USB input I2S to BII.
A FifoPI Q2 Ultimate was added to the RPI. Works fine with USB output however the goal is the use I2S out from the FifoPI straight to the BII (and eventually BIII).
I have verified the I2S connections but here it gets a bit wooly with three different nomenclatures for the same Uf.L terminals.
Please help me out here and verify the following is correct.
From FifoPi manual to FifoPi board:
MCLK = MCLK
SCK = SCK
LRCK/D1 = LR/DO
SD/D2 = SD/D1
Then from FifoPi Board to BII (for async mode):
DCK to BCK
LR/DO to D1
D2 to Data
Please verify if this correct or let me know what is.
If it correct then problem may be software as RopieeXL does not have a Fifo hat connection and there is an indication of "hardware mixer not supported" when trying to select various outputs. How to get it to pass I2S?
In any case with various output settings Roon cannot see the endpoint with the above connections.
So how best to reclock RPI running RopieeXL and get I2S out put for BII (and eventually BIII)?
Does the RPI OS need to change or are there configuration settings which would allow this?
Any help appreciated!
Cheers,
Chuck
need a little help in understanding the Ian Canada architecture please.
How to adapt an RPI with these devices to output I2S to Buffalo II (and eventually BIII)?
PC Roon server RJ45 to RPI running RopieeXL with USB out to Wave I/O USB input I2S to BII.
A FifoPI Q2 Ultimate was added to the RPI. Works fine with USB output however the goal is the use I2S out from the FifoPI straight to the BII (and eventually BIII).
I have verified the I2S connections but here it gets a bit wooly with three different nomenclatures for the same Uf.L terminals.
Please help me out here and verify the following is correct.
From FifoPi manual to FifoPi board:
MCLK = MCLK
SCK = SCK
LRCK/D1 = LR/DO
SD/D2 = SD/D1
Then from FifoPi Board to BII (for async mode):
DCK to BCK
LR/DO to D1
D2 to Data
Please verify if this correct or let me know what is.
If it correct then problem may be software as RopieeXL does not have a Fifo hat connection and there is an indication of "hardware mixer not supported" when trying to select various outputs. How to get it to pass I2S?
In any case with various output settings Roon cannot see the endpoint with the above connections.
So how best to reclock RPI running RopieeXL and get I2S out put for BII (and eventually BIII)?
Does the RPI OS need to change or are there configuration settings which would allow this?
Any help appreciated!
Cheers,
Chuck
I appreciated learning more about the characteristics of FIFO and its role in my system. Timing is a tough topic though. Almost always has an element of you don't understand... no you don't understand. But I always feel I learn a little even if not qualified to participate.
Andrea's Well Tempered Master Clock pairs with Ian's FIFOPi like great wine and cheese. Great there are smart people who understand the science behind it.
Hi Andrea,
I for one, and I am sure a lot of others, am very interested in your measurements on the fifopi.
I use the fifopi with one of your driscoll clock designs and will surely buy your new clocks as I am confident that these will surpass the current design on the fifopi!
So please do publish the measurements in this thread.
PS. I respect Ian and you both as very competent designers (using both your designs) you might not agree on all details but I am sure you Also respect each other.
Regards,
guys if you ask me there are often more damages around the decoupling and power supplies topologies than jitter arm around that clocks, fifo, etc: at least for pcm dac chips, for brand new delta sigmas' : I really don't know - not using them anymore-
But both of all world is what we, audio fanatics, are trying to targett
I use complete 2nd Ian's clock board complete stuffs and also first gen FifoPi. with Crysteks ... that finally can be improved from sound with better decoupling and care about reg chips... seems Greg bands makes big progress : supercaps, etc... AND, a big one, it's hard to work for audio with Rpis...
But both of all world is what we, audio fanatics, are trying to targett
I use complete 2nd Ian's clock board complete stuffs and also first gen FifoPi. with Crysteks ... that finally can be improved from sound with better decoupling and care about reg chips... seems Greg bands makes big progress : supercaps, etc... AND, a big one, it's hard to work for audio with Rpis...
Both of the configurations are correct
For sync mode (have to remove the XOs on the BIII)
MCLK = MCLK
SCK = SCK
LRCK/D1 = LR/DO
SD/D2 = SD/D1
For async mode (defualt)
DCK to BCK
LR/DO to D1
D2 to Data
BIII doesn't support 44.1KHz 16bit, so have to enable 16 to 32 lossless convertor on FifoPi.
I have a BII SE, I don't have any problem. But please make sure DAC jumpers are set correctly.
Regards,
Ian
SPDIF board with FIFO 1 and Si570 clock boards
Hi guys
Need a bit of help to supply the SPDIF board with a MCLK feed when using the FIFO (vers 1) and Si570 clock boards.
In the Si570 user manual ir states:
"The Si570 Clock Board operates in the double speed mode natively. It is not recommended to feed its MCLK into the DIT section of the S/PDIF board as part of a S/PDIF FIFO..........If necessary, the MCLK from the FIFO board may be fed to the S/PDIF Interface board MCLK U.FL socket".
I sucessfully managed to get everything working with the MCLK output (J1) from the single xo clock test board that came with the FIFO 1 board but now I've switched clocks I cannot use the MCLK outputs on the Si570 board (see above) and I can't find a MCLK output on the FIFO 1 board
The only MCLK connection (on the FIFO 1 board) I can find is the MCLK input U.FL (J6).
Ian or anyone; where do I get the SPDIF MCLK input from my FIFO 1 board?
Thanks
Hi guys
Need a bit of help to supply the SPDIF board with a MCLK feed when using the FIFO (vers 1) and Si570 clock boards.
In the Si570 user manual ir states:
"The Si570 Clock Board operates in the double speed mode natively. It is not recommended to feed its MCLK into the DIT section of the S/PDIF board as part of a S/PDIF FIFO..........If necessary, the MCLK from the FIFO board may be fed to the S/PDIF Interface board MCLK U.FL socket".
I sucessfully managed to get everything working with the MCLK output (J1) from the single xo clock test board that came with the FIFO 1 board but now I've switched clocks I cannot use the MCLK outputs on the Si570 board (see above) and I can't find a MCLK output on the FIFO 1 board
The only MCLK connection (on the FIFO 1 board) I can find is the MCLK input U.FL (J6).
Ian or anyone; where do I get the SPDIF MCLK input from my FIFO 1 board?
Thanks
Last edited: