I sold my Chord mScaler, so I plan to hold off on the LiFePO4 stack. I was hoping to feed 13.2 in parallel and see how many hours I would get. I think the LiFePO4 project is overkill now for what I want to accomplish so I think it's best to hold off for now. My main purpose for the LifePO4 stack was the 2x13.2 lanes for the mScaler. My needs have changed and just need 3.3 for now...
This allows me to just focus on a minimalist FiFoPi Q3 + TransportPi (optical) build to experiment with clock-rolling.
But I'm not sure whether to pursue the RPI-less route ATM.
Does anyone recommend the IsolatorPI for the i2s -> RPI-less?
I was considering #20 -> RPi-less, but it seems cleaner with the IsolatorPI.
Also, does the IsolatorPi run off the GPIO power?
I'm curious how much of a noise difference this will make to have a separate RPi/Odroid -> RPI-less setup. If it's worth the effort versus just using a traditional RPi + FiFoPi + TransportPi stack. Or is the IsolatorPi a legacy product that's no longer needed in the chain?
This allows me to just focus on a minimalist FiFoPi Q3 + TransportPi (optical) build to experiment with clock-rolling.
But I'm not sure whether to pursue the RPI-less route ATM.
Does anyone recommend the IsolatorPI for the i2s -> RPI-less?
I was considering #20 -> RPi-less, but it seems cleaner with the IsolatorPI.
Also, does the IsolatorPi run off the GPIO power?
I'm curious how much of a noise difference this will make to have a separate RPi/Odroid -> RPI-less setup. If it's worth the effort versus just using a traditional RPi + FiFoPi + TransportPi stack. Or is the IsolatorPi a legacy product that's no longer needed in the chain?
Attachments
Last edited:
1. that is very kind of you! Thank you!
2. it was also very kind of the person sending you the board! I thank him too.
Do you habe the latest board then? Are there still the isolators from SI on it? I thought that there was a tendency towards the nve il715? And is there still the 74hvlc flip flop on it? I still can‘t believe that flip flops do a really good job for this purpose. I have never seen a flip flop Datasheet stating anything in the direction of additive jitter - because it was not purposed for this or?
I am curious sometimes. On one hand this diy audio community is requesting a thousand different measurements and discusses every little chip for it’s data, and on the other hand, well. Nothing, just the believe in a good design and some fellows saying it’s a good product. Well, you know which group I’m in
I’m looking forward to your results! I have looked at many Isolator ic datasheets already, but have not learned anything in university yet, but can there be any adavantage on isolating the I2S signal twice? (Just in terms of isolation from Noise from FIFO, jitter is of course horrible after isolator).
I‘m not sure here but is the incoming I2S signal from the RPi already isolated before going into the FIFO? There is another isolator on Button of the board or is it for i2c isolation?
So, two new questions: If the incoming I2S from RPi is isolated, and the signal is again isolated after the FIFO, where does the power come from to the reclocker? If the incoming I2S from RPi is not isolated; why is it not isolated?
To sum that up: If the jitter in the non-isolated output was indeed lower. I will proceed and connect my dam1021 to the non isolated outputs. If the jitter was really better after the isolator and Flip Flop I will have to remove the onboard isolators of my dam1021. Puh.
Last edited:
@janho12345
I will receive the FifoPi Ultimate V1 but I don't know its architecture (isolator, flip-flop and so on), I have never seen a schematic in this thread, maybe the designer could explain.
Your questions are all rightful, but as I said above only the designer can answer.
I will measure the phase noise of BCK and WS at the input and at the output of the FifoPi to understand if the jitter of the source is really removed.
Comparing the plots you will be able to evaluate the efficiency of the reclocker.
I will receive the FifoPi Ultimate V1 but I don't know its architecture (isolator, flip-flop and so on), I have never seen a schematic in this thread, maybe the designer could explain.
Your questions are all rightful, but as I said above only the designer can answer.
I will measure the phase noise of BCK and WS at the input and at the output of the FifoPi to understand if the jitter of the source is really removed.
Comparing the plots you will be able to evaluate the efficiency of the reclocker.
Ignore, I have to independently power the IsolatorPi so dealbreaker since I don't have a MKIII ATM.
I'll turn my attention to the BridgePi once more info is released and maybe a ConditionerPi to wrap up first build.
1. that is very kind of you! Thank you!
2. it was also very kind of the person sending you the board! I thank him too.
Do you habe the latest board then? Are there still the isolators from SI on it? I thought that there was a tendency towards the nve il715? And is there still the 74hvlc flip flop on it? I still can‘t believe that flip flops do a really good job for this purpose. I have never seen a flip flop Datasheet stating anything in the direction of additive jitter - because it was not purposed for this or?
I am curious sometimes. On one hand this diy audio community is requesting a thousand different measurements and discusses every little chip for it’s data, and on the other hand, well. Nothing, just the believe in a good design and some fellows saying it’s a good product. Well, you know which group I’m in
I’m looking forward to your results! I have looked at many Isolator ic datasheets already, but have not learned anything in university yet, but can there be any adavantage on isolating the I2S signal twice? (Just in terms of isolation from Noise from FIFO, jitter is of course horrible after isolator).
I‘m not sure here but is the incoming I2S signal from the RPi already isolated before going into the FIFO? There is another isolator on Button of the board or is it for i2c isolation?
So, two new questions: If the incoming I2S from RPi is isolated, and the signal is again isolated after the FIFO, where does the power come from to the reclocker? If the incoming I2S from RPi is not isolated; why is it not isolated?
To sum that up: If the jitter in the non-isolated output was indeed lower. I will proceed and connect my dam1021 to the non isolated outputs. If the jitter was really better after the isolator and Flip Flop I will have to remove the onboard isolators of my dam1021. Puh.
Hi Jan,
i hope you don´t mind if i step in into this conversation, but maybe i can provide some clarification...
the Header J2 is not a seperate output, its just a duplication of the input header J1 (all pins direcktly
connected) in case you need access to the GPIO for some reason, e.g. Ian´s ESS controller is
connected that way.
the FIFO does not improve the I2S signal, it´s just a buffer.
the idea behind a "asynchonous FIFO reclocker" is to have a reclocker to improve the I2S-signal in a
standalone unit. if you don´t synchronise the time domains of the source and the reclocker one signal will
always be slightly slower or faster than the other, thats why you need the FIFO, which can buffer
the signal for some time.
and yes, the isolator add alot of jitter ( i think ca. 100ps), but if you place the isolator before the
flip-flop and the overall layout is done right all that extra jitter gets erased by the reclocker.
and, yes, the second isolator is obviously for the I2C.
and about the layout of the fifoPi: when you follow the traces on the board, ypu can clearly see, that the
I2S lines go directly from the FPGA to the isolator, then to the flip-flop and from there to the U.fl sockets.
and lastly about the dam1021: it has a FIFO reclocker build in, and Søren says, therefore it´s imune
to any bad input signal, but many users have reported, that when you feed a soekris R2R with a RPI
a FifoPi does improve the SQ.
...but, when you have a fifoPi and a dam1021, why do you have to ask about this ?
you should be able to hear it fo yourself...
FifoPi testing result: (1) How bad are the I2S signals from a RaspberryPi GPIO
I'm so sorry if I reply posts lately. I'm really busy under this very special situation, even don't have enough time listening to music. Just hope I had 30 hours a day.
Nine years ago, I developed a first FIFO for this audiophile community. Since then, I have been continuous doing the developing jobs and posted many things related to FIFO principle. And now, seems a lot of people are wondering by how much a FIFO can can remove jitter from income digital audio signals. So I decide to do some real test to FifoPi Q2 and share the testing result with you.
The first test is to measure the RaspberryPi I2S jitter from GPIO
Here is the test conditions:
RapberryPi 4 B
Volumio play 44.1KHz 16bit music
Pick up SCK signal from RPi GPIO
LC584AXL with jitter package
Testing result:
SCK carry frequency 1.40948MHz (tolerance 4.36KHz)
SCK RMS period jitter 682.7ps
(My oscilloscope has jitter measurement noise floor of 3ps, so the result should be around 679.7ps)
The jitter histogram has two peaks, which is the typical DPLL signature (You can roughly understand how a RPi generates audio clock).
I have testing results of many other streamers, RPi is not the worse case. But even for consumer grade audio devices, this 679.7ps jitter is already too much.
Please see my testing result for more details.
RPiSCK44.1K16bitold by Ian, on Flickr
Ian
I'm so sorry if I reply posts lately. I'm really busy under this very special situation, even don't have enough time listening to music. Just hope I had 30 hours a day.
Nine years ago, I developed a first FIFO for this audiophile community. Since then, I have been continuous doing the developing jobs and posted many things related to FIFO principle. And now, seems a lot of people are wondering by how much a FIFO can can remove jitter from income digital audio signals. So I decide to do some real test to FifoPi Q2 and share the testing result with you.
The first test is to measure the RaspberryPi I2S jitter from GPIO
Here is the test conditions:
RapberryPi 4 B
Volumio play 44.1KHz 16bit music
Pick up SCK signal from RPi GPIO
LC584AXL with jitter package
Testing result:
SCK carry frequency 1.40948MHz (tolerance 4.36KHz)
SCK RMS period jitter 682.7ps
(My oscilloscope has jitter measurement noise floor of 3ps, so the result should be around 679.7ps)
The jitter histogram has two peaks, which is the typical DPLL signature (You can roughly understand how a RPi generates audio clock).
I have testing results of many other streamers, RPi is not the worse case. But even for consumer grade audio devices, this 679.7ps jitter is already too much.
Please see my testing result for more details.
RPiSCK44.1K16bitold by Ian, on Flickr
Ian
I can see that now, we’ll I thought the design to be even better.
I don’t know the ultimate truth and can only speak for myself but synchronisation of Input and output is not what we want here.
For me, the idea of this FIFO is written on page one of this thread. There is a diagram as well.
So we agree here? Isolation should take place before the FIFO (and afterwords, too?)
As Ian did not answer to you post, I think I’ll try to explain again, why I thought about J2 outputs and what I thought they were.
As I understand the the function of this device, (asynchron First in First out) is to plainly buffer the incoming i2s signal. By buffering, the timing on these data gets lost. To send out a new i2s stream, an external MCKl is used for generating these signals. For me, this is a real “re-clocked” signal.
Hence we have a new i2s signal and of course with the old data, only timing wise. I understood (Or better) wanted to understand the manual in that way, that J2 has the i2s signal after FIFO but without iso and re-ckl. Kind of like the FiFi II The other thing happening on the board is isolation after the FiFo and because of this isolation there is a FlipFlop for re-clocking. But for me this kind of reclocking is strange. As these Flip Flops were not build for this application.
It would make sense to me, to isolate the FIFO from the RPi and make the output isolation optional.
So, Andrea_Mori if you can hear me, I need measurement of i2s signal after flip flop and before isolators! Not from J2. Thank you
Last edited:
Not exactly, a well designed architecture remove all the jitter coming from the source. The only limit is the phase noise of the oscillator. You don't need any reclocker, the FIFO buffer is asynchronous, it has to be slaved to the master clock. This explains a proper architecture
Building the ultimate NOS DAC using TDA1541A
How does your oscilloscope measure the jitter?
As you know the calculated jitter depends on the integration bandwidth.
You should measure the phase noise rather than the jitter, phase noise is absolute while jitter is strictly related to the integration bandwidth used for the measurement.
I can not remember to have seen an artificial bandwidth limit in a LeCroy jitter package. So I assume the bandwidth limit equals the scope bandwidth.
The scope, a LeCroy LC584AXL, is running at maximal sample rate and the 50Ohm input impedance is used. So the most likely setup is that no probe is used but the source is directly connected by a cable to the scope and thus the bandwidth is the full scope bandwidth of 1GHz.
P.S. there is no integration. the scope measures in the time domaine, so measure the jitter directly.
The scope, a LeCroy LC584AXL, is running at maximal sample rate and the 50Ohm input impedance is used. So the most likely setup is that no probe is used but the source is directly connected by a cable to the scope and thus the bandwidth is the full scope bandwidth of 1GHz.
P.S. there is no integration. the scope measures in the time domaine, so measure the jitter directly.
Jitter is a relative measurement, so the result depends on the integration bandwidth.
A measurement close to the carrier shows higher jitter than a measurement far from the carrier.
In digital to analog conversion we look for the best short term stability, we don't care about long term stability.
So, it's crucial that the lower limit of the integration bandwidth is close to the carrier, that means not more than 10 Hz from the carrier, better if it's 1Hz from the carrier. While we don't care about the upper limit of the integration bandwidth.
This is the reason why is better measure the phase noise rather than the jitter, phase noise is absolute, not bandwidth dependent.
If the integration bandwidth is not known the jitter value does not say nothing.
You can find a lot of "phase noise to jitter converter" on the web (or if you want "frequency domain to time domain converter") that help to understand. Try adding measurement points each time closer to the carrier and you will see the jitter grows exponentially.
A jitter value of 600 ps says nothing if the lower limit of the integration bandwidth is not known.
A measurement close to the carrier shows higher jitter than a measurement far from the carrier.
In digital to analog conversion we look for the best short term stability, we don't care about long term stability.
So, it's crucial that the lower limit of the integration bandwidth is close to the carrier, that means not more than 10 Hz from the carrier, better if it's 1Hz from the carrier. While we don't care about the upper limit of the integration bandwidth.
This is the reason why is better measure the phase noise rather than the jitter, phase noise is absolute, not bandwidth dependent.
If the integration bandwidth is not known the jitter value does not say nothing.
You can find a lot of "phase noise to jitter converter" on the web (or if you want "frequency domain to time domain converter") that help to understand. Try adding measurement points each time closer to the carrier and you will see the jitter grows exponentially.
A jitter value of 600 ps says nothing if the lower limit of the integration bandwidth is not known.
You mix up phase noise and jitter. The close in phase noise is higher, yes, but contributes next to nothing to the jitter due to its relative small occupied 'frequency band', regardless if you include it to the integration or not - try it with your mentioned jitter converter.
The phase noise in e.g. 10Hz offset to the clock has no '10Hz offset effect' to the in the produced audio ... thus marketing statements, that the clock has low phase noise in the audio band, e.g. below 20kHz, are nonsense ... at least if you interpret them naively.
The phase noise in e.g. 10Hz offset to the clock has no '10Hz offset effect' to the in the produced audio ... thus marketing statements, that the clock has low phase noise in the audio band, e.g. below 20kHz, are nonsense ... at least if you interpret them naively.
10Hz offset to the clock hevily affects the digital to analog conversion.
The jitter measured with an integration bandwidth starting at 100 Hz from the carrier is almost the same for most oscillators, including the standard one provided by Ian, the Crystek, the NDK, the Pulsar and maybe the SOTA oscillators like Wenzel and Oscilloquartz.
What makes the difference is just the close in jitter (in time domain or phase noise in frequency domain, the same thing viewed from a different point of analysis), that's the reason why the best converters on the market are focused on very low phase noise oscillators.
Please try the jitter converter to understand. I have no time to do it for you.
To get simpler, why people replace the standard oscillator provided by Ian with at least a Crystek oscillator (or a better one, since it's not a low jitter oscillator)?
Starting from your statement it looks like that most members have not understood, replacing the oscillator is unuseful.
Please, let me know, I'm curious to know a different point of view.
The jitter measured with an integration bandwidth starting at 100 Hz from the carrier is almost the same for most oscillators, including the standard one provided by Ian, the Crystek, the NDK, the Pulsar and maybe the SOTA oscillators like Wenzel and Oscilloquartz.
What makes the difference is just the close in jitter (in time domain or phase noise in frequency domain, the same thing viewed from a different point of analysis), that's the reason why the best converters on the market are focused on very low phase noise oscillators.
Please try the jitter converter to understand. I have no time to do it for you.
To get simpler, why people replace the standard oscillator provided by Ian with at least a Crystek oscillator (or a better one, since it's not a low jitter oscillator)?
Starting from your statement it looks like that most members have not understood, replacing the oscillator is unuseful.
Please, let me know, I'm curious to know a different point of view.
Of course the quality of the oscillator matters!
The problem is the interpretation of the measurements, the caused effects and the claimed 'facts'.
But it starts to get off topic. If I find the nerve and time to do a proper write up on the oscillator topic I'll start a new thread and for sure let you know.
The problem is the interpretation of the measurements, the caused effects and the claimed 'facts'.
But it starts to get off topic. If I find the nerve and time to do a proper write up on the oscillator topic I'll start a new thread and for sure let you know.
Please, explain the following jitter plots, the first is the Crystek CCHD-957 at 45.1584 MHz and the second is the Pulsar Clock at the same frequency.
From your statement about the integration bandwidth I have calculated the jitter with a lower limit of 100 Hz from the carrier, taking phase noise data from datasheet (no jitter declared, phase noise only, that's logic).
As you can see from the plots the Crystek is much better than the Pulsar Clock, 12.76 fS against 21.41 fS.
Is that right?
If so, why the Crystek costs a fraction of the Pulsar Clock?
