Hello
im trying to figure out what impact the clocks of the raspberry pi 4 have and i wanna exchange them but i need a little help since im not too keen on electronics
there are 2 chinese hats i found which do the job:
http://home.teradak.com/products/118.html
https://www.thanksbuyer.com/ustars-...mv85-for-raspberry-pi-4b-change-crystal-73302
but im kinda wondering which would be the better approach
1. one 10mhz oxco master clock where the 25mhz and 54mhz clock signal are derived from for the raspberry pi
2. or seperat 25mhz/54mhz txco clocks
and im curious if i even need one of those boards, would it be easy to implement two txco clocks just by myself? do i even need additonal circuitry or can i power one of those txco clocks directly with 3,3 and just hook up the output to the clock input pad on the raspberry pi after i removed the existing clock? i actually dont think there is much needed circuitry wise beside maybe a few caps?
any help is much appreciated (as long it isnt "this doesnt matter" advice, i wanna test it myself 🙂 )
im trying to figure out what impact the clocks of the raspberry pi 4 have and i wanna exchange them but i need a little help since im not too keen on electronics
there are 2 chinese hats i found which do the job:
http://home.teradak.com/products/118.html
https://www.thanksbuyer.com/ustars-...mv85-for-raspberry-pi-4b-change-crystal-73302
but im kinda wondering which would be the better approach
1. one 10mhz oxco master clock where the 25mhz and 54mhz clock signal are derived from for the raspberry pi
2. or seperat 25mhz/54mhz txco clocks
and im curious if i even need one of those boards, would it be easy to implement two txco clocks just by myself? do i even need additonal circuitry or can i power one of those txco clocks directly with 3,3 and just hook up the output to the clock input pad on the raspberry pi after i removed the existing clock? i actually dont think there is much needed circuitry wise beside maybe a few caps?
any help is much appreciated (as long it isnt "this doesnt matter" advice, i wanna test it myself 🙂 )
i found these two boards, would they already be enough if i wanna do it myself? atleast it looks like it
and i kinda like the more simple approach, so i can even use LT3045 LDO`s to power them instead of some lower quality LDO baked onto the board
https://www.ebay.de/itm/174216558760
https://www.ebay.com/itm/123572104994
and i kinda like the more simple approach, so i can even use LT3045 LDO`s to power them instead of some lower quality LDO baked onto the board
https://www.ebay.de/itm/174216558760
https://www.ebay.com/itm/123572104994
I would try a separate power supply to the existing clock before replacing it.
Need to verify that any delay from such a setup won’t interfere with any potential starting sequence however.
At the very least, you might check and see if they use a ferrite bead on the power for the clock on that board, helps on a typical DAC anyways. I have done that by allowing a lead from a capacitor to extend enough to be able to add a small ferrite over it.
Need to verify that any delay from such a setup won’t interfere with any potential starting sequence however.
At the very least, you might check and see if they use a ferrite bead on the power for the clock on that board, helps on a typical DAC anyways. I have done that by allowing a lead from a capacitor to extend enough to be able to add a small ferrite over it.
hmm yes this could be indeed a problem if i use a seperate LT3045 LDO and the same 5V rail to power the cm4, i hope it works, worst case i think is that i have to power the clocks beforehand (or delay the 5V rail to the rpi4 somehow)
i dont think they use ferrite beads, its a good point
right now i thinking about using this board https://www.ebay.de/itm/174216558760 and maybe try to improve it (for example ferrite bead and power capacitor bank would be optimizeable or design a own version of it later on) but for a initial test to see if clocks make a difference its probably enough
but i still need help to figure out if i even can use this board
What is the purpose? Driving the i2s bit clock more accurately?
Oven and temp compensated clocks are good for long term stability but what about phase noise? You could use a low phase noise oscillator with a low noise power supply.
Oven and temp compensated clocks are good for long term stability but what about phase noise? You could use a low phase noise oscillator with a low noise power supply.
well in general to improve things but i dont wanna claim that it actually does since i have not tested it yet (i know its all digital and stuff) but i wanna check for myself! since i try to build mainly a "(noise)optimized" audio streamer, maybe the clocks do nothing but if the rpi4 still works with new clocks i can atleast sleep better since i have tried 😀
low jitter/low phasenoise/stability are my main concerns, if clocks make a difference its probably the right place to test it (if it makes a difference in computer) since the stock clocks seem rather crappy compared to high performance clocks
but yes i agree, the clock exchange probably makes the most difference with i2s (maybe it even helps if you even use a fifo reclocker? since the input signal integrity will be better to begin with)
i also noticed changes if you underlock the raspberry pi and optimize it on a os/kernel level sq-wise, thats why i got curious what new clocks can "potentially" do, i dont wanna go into a discussion IF it makes a difference but i just wanna try (and will report back my findings!)
I've a little experience in the kernel/i2s in exploring the clocking capability and then switching to a STM32F7 (I'm beginner but perhaps dived into this enough to at least understand some basics). At the moment I'm using a SDG clock gen to provide the clock signal required but my intent is to use an NSK (ie very low jitter) oscillator with a fanout to provide a clocking signal. The NSK is also used in an old m-audio interface so I've looked at the jitter on that - inseams to be about 0.2ns from memory (unshielded probes etc).
Phase noise is either the oscillator itself or the noise from the power supply of subsequent processing of the signal. It's the close in phase noise that you want to target for audio. Audio sampling and replay are too short (and low enough frequency) for long term stability not to be a requirement. If you're sampling over years with precision then ignore that last remark. You can use phase locked loops etc but all subsequent processing adds noise unless you start using advanced techniques (such as phase correlation of duplicate channels) to provide a higher signal to noise ratio. However that's normally reserved for frequency sources and high end spectrum analysers etc (if you watch SignalPath YouTube videos you may see a couple of those in teardown/repair videos).
There is a mathematical formulae that links the number of bits you have (and noise) to the jitter/phase noise. Any less will result in bad ADC/DAC results but any more is simply human emotional statistical comfort and is very unlikely to actually do anything for your playback (other than lower the noise floor).
The RPI4's clocking is not perfect by any means, and using oven or temp oscillators will help it's longer term realtime clock stability for programming but the underlying OS isn't a realtime OS. Nor is the board designed for the lowest noise possible. For that reason - the most effective form (ie the best return for effort) is a FIFO re-clocker. My little project of a USB to i2s STM32F7 interface essentially provides FIFO rechecking with the NSK oscillator driving the input/output i2s.
This is why I decided to look at designing a simple low phase noise NSK and a low phase noise fanout IC with .. you guessed a low noise power supply. The fanout then drives four signals synchronously - one for the ADC, one for the later DAC, one for external BNC and the final being in reserve. They are decoupled so noise on one channel doesn't effect the others and the same IC acts like a driver to prevent loading down the oscillator.
So it's probably safe to say that a clock replacement for the RPI is probably better than the internal generated clock, regardless of the external oscillator type. However in the end, using a FIFO and re-clocking the signal will give the best results. Add to the RPi's woes is that I suspect the standard crystal's high frequency down clock PLL loop is supplied by a power supply that has both noise and a ground that is probably not particularly quiet in chip and so has ground bump. Good enough for being an RPI but not.. perhaps for reducing jitter.
At some point the brain's operating speed is below the phase noise frequency.. and I don't think any audiophile would admit that they can't hear the difference.
Phase noise is either the oscillator itself or the noise from the power supply of subsequent processing of the signal. It's the close in phase noise that you want to target for audio. Audio sampling and replay are too short (and low enough frequency) for long term stability not to be a requirement. If you're sampling over years with precision then ignore that last remark. You can use phase locked loops etc but all subsequent processing adds noise unless you start using advanced techniques (such as phase correlation of duplicate channels) to provide a higher signal to noise ratio. However that's normally reserved for frequency sources and high end spectrum analysers etc (if you watch SignalPath YouTube videos you may see a couple of those in teardown/repair videos).
There is a mathematical formulae that links the number of bits you have (and noise) to the jitter/phase noise. Any less will result in bad ADC/DAC results but any more is simply human emotional statistical comfort and is very unlikely to actually do anything for your playback (other than lower the noise floor).
The RPI4's clocking is not perfect by any means, and using oven or temp oscillators will help it's longer term realtime clock stability for programming but the underlying OS isn't a realtime OS. Nor is the board designed for the lowest noise possible. For that reason - the most effective form (ie the best return for effort) is a FIFO re-clocker. My little project of a USB to i2s STM32F7 interface essentially provides FIFO rechecking with the NSK oscillator driving the input/output i2s.
This is why I decided to look at designing a simple low phase noise NSK and a low phase noise fanout IC with .. you guessed a low noise power supply. The fanout then drives four signals synchronously - one for the ADC, one for the later DAC, one for external BNC and the final being in reserve. They are decoupled so noise on one channel doesn't effect the others and the same IC acts like a driver to prevent loading down the oscillator.
So it's probably safe to say that a clock replacement for the RPI is probably better than the internal generated clock, regardless of the external oscillator type. However in the end, using a FIFO and re-clocking the signal will give the best results. Add to the RPi's woes is that I suspect the standard crystal's high frequency down clock PLL loop is supplied by a power supply that has both noise and a ground that is probably not particularly quiet in chip and so has ground bump. Good enough for being an RPI but not.. perhaps for reducing jitter.
At some point the brain's operating speed is below the phase noise frequency.. and I don't think any audiophile would admit that they can't hear the difference.
Last edited:
yes i agree, you are probably right and objectively you definitly have points there
tho, i heared how different OS`s change the SQ and also how different power supplys affect it, this makes me believe the clocks could -potentially- too, like i said, i just wanna try to check, i dont care for 50€, if it could potentially help to close the gap between the RPI (which i really like since its opensource, CamillaDSP is one huge benefit for me) and high end streamers