For the RPI there are many types of USB interfaces and reclockers available. Many of them seem to be overly complex.
I am wondering what the reason is for not using the following approach (assuming the DAC only operates in I2S slave mode)
- RPI/Rock64 in I2S master mode, with MCLK as input.
- Low jitter MCLK next to the DAC
- Some flipflops at the DAC inputs to synchronize I2S to the MCLK clock
- Use the same (divided) MCLK to feed the RPI I2S_MCLK input.
Putting an I2S isolator before the flipflop would also be possible without introducing additional jitter.
Is there some reason why this would not be possible ?
I am wondering what the reason is for not using the following approach (assuming the DAC only operates in I2S slave mode)
- RPI/Rock64 in I2S master mode, with MCLK as input.
- Low jitter MCLK next to the DAC
- Some flipflops at the DAC inputs to synchronize I2S to the MCLK clock
- Use the same (divided) MCLK to feed the RPI I2S_MCLK input.
Putting an I2S isolator before the flipflop would also be possible without introducing additional jitter.
Is there some reason why this would not be possible ?
Last edited:
MCLK might be too high frequency for RPi to handle as an input. To generate I2S clocks it would presumably have to count MCLK pulses very quickly while doing other things at the same time. Consider than some dac clocks are running at around 49MHz.
In addition, RPi generates quite a bit of conducted and radiated RFI/EMI, particularly so for latest and fastest version. Simply relatching I2S signals might not be enough to assure ideal dac operation. In my view, hat dacs may be cute but they are not optimal. Better to use well isolated USB.
In addition, RPi generates quite a bit of conducted and radiated RFI/EMI, particularly so for latest and fastest version. Simply relatching I2S signals might not be enough to assure ideal dac operation. In my view, hat dacs may be cute but they are not optimal. Better to use well isolated USB.
The PCM/I2S peripheral of the RPi SoC does not have an external MCLK input with a configurable divider down to bitclock. Actually I do not think any of the SoC's internal fractional dividers can be fed by an external signal. It would be a handy feature for many uses.
It offers only external bitclock (and external frame clock, optionally) which must be generated from an external master clock externally.
It offers only external bitclock (and external frame clock, optionally) which must be generated from an external master clock externally.
@Markw4 The idea was to have a hardware divided MCLK, handling it in software would indeed not be possible due to the high frequency (> 22MHz)
@phofman
Based on some discussions on websites/forums and some commercially available ADC hats for the RPI, I was under the impression that it would be possible. When I started to look into the CPU manual I noticed the same as you mention. It is not possible to provide an external MCLK for the I2S peripheral, only BCLK in slave mode.
My second option is a Rock64. I have do do some more reading, but so far, it seems that according to the RK3328 CPU manual an external MCLK can be provided for the I2S interface. It seems as well that the required pin is available at the header. The RK3328 also provides an SPDIF output. This makes the Rock64 more suitable for use as audio player compared to an RPI4. I also like the idea that there is an option for eMMC.
@phofman
Based on some discussions on websites/forums and some commercially available ADC hats for the RPI, I was under the impression that it would be possible. When I started to look into the CPU manual I noticed the same as you mention. It is not possible to provide an external MCLK for the I2S peripheral, only BCLK in slave mode.
My second option is a Rock64. I have do do some more reading, but so far, it seems that according to the RK3328 CPU manual an external MCLK can be provided for the I2S interface. It seems as well that the required pin is available at the header. The RK3328 also provides an SPDIF output. This makes the Rock64 more suitable for use as audio player compared to an RPI4. I also like the idea that there is an option for eMMC.
@output, have you seen Twisted Pear's project to supply isolated external clocks to a BeagleBone Black single board computer -
Hermes-BBB/Botic cape for BeagleBone Black
Hermes-BBB/Botic cape for BeagleBone Black
@linuxfan Thanks for the tip, didn't see that site for a long time. Actually a few years ago I also used a BBB as I2S slave, but for now I like to have something with a bit more processing power.
I think I will change plans. The Rock64 seems nice, but I read many people which are not satisfied with it in terms of drivers and stability.
I might reconsider the RPI4, which at least supports I2S slave mode, then provide an own master clock, which is also used to generate the bitclock. Similar to what Twisted pear does.
I do not want too many diffent modules, just a baseboard, which also hosts the SBC and only digital logic and I2S isolation and a completely separate DAC PCB/PSU. Will look again into the RPI4. Before I used a BBB I used the 2nd generation RPI for an audio player, but I abandonded it, relaibility issues with SD card corruption. Have never had that with the BBB which is still in use for more than 2 years now. Wonder how the new RPI is, which unfortunately lacks eMMC.
I think I will change plans. The Rock64 seems nice, but I read many people which are not satisfied with it in terms of drivers and stability.
I might reconsider the RPI4, which at least supports I2S slave mode, then provide an own master clock, which is also used to generate the bitclock. Similar to what Twisted pear does.
I do not want too many diffent modules, just a baseboard, which also hosts the SBC and only digital logic and I2S isolation and a completely separate DAC PCB/PSU. Will look again into the RPI4. Before I used a BBB I used the 2nd generation RPI for an audio player, but I abandonded it, relaibility issues with SD card corruption. Have never had that with the BBB which is still in use for more than 2 years now. Wonder how the new RPI is, which unfortunately lacks eMMC.
If you are planning on designing your own baseboard, you might want to consider using the compute module CM4 instead of RPi4. It has eMMC as an option (cheaper than RPi4 with a decent SD card), you can place connectors as needed, you can route your I2S shorter. USB and HDMI connectors cost nothing. The CM4 IO board comes with full documentation, including PCB in kicad (very convenient to reuse for your design). The inexpensive CM4 connectors are readily available from mouser and farnell.
I have used RPi's for audio for 6 years, most of the models, and don't remember ever having a SD corruption. I did have a application suddenly not work a few weeks ago but once in 6 years is not bad odds.
So I'd say the RPi's are reliable. It could have been unreliable software, unreliable SD card or unreliable power supply though?
Yes. Good practice, then, is to issue a proper shutdown command before removing power.
For the BeagleBones, all you need to do is briefly GND the "PWR_BUT" pin of the TPS65217C power management chip (pin 9 of expansion header).
For most other SBC's you should run a bash script or python script to watch for a switch closure of a GPIO pin, to initiate the shutdown command.
From what I have read (no personal experience) the problem with RPi and SD card was a slowly dropping voltage at poweroff (brown-out) which presumably SD cards do not like. I have seen many many reports of damaged SD cards (not their data, but the physical hardware). I do not know if RPi4 has changed the SD-card power arrangement, but do not recall reading about such an improvement.
Those using RPIs at large report 3 to 12 months of standard SD-card lifetime. These "powerusers" do not have the SD-card partition mounted read-only filesystem, have logging enabled, etc. I would not take that as a relevant reference for a proper audio player with read-only SD-card partition. Nevertheless an embedded device (unlike a PC) must be able to survive a repeated power cut, when no shutdown script is able to run.
Industrial-quality SD cards cost more than RPi itself, decent non-industrial models still fetch a substantial part of the BOM. IMO an SD card is not the best practice in an embedded device. That is why I am very glad the CM4 finally offers the eMMC option.
Those using RPIs at large report 3 to 12 months of standard SD-card lifetime. These "powerusers" do not have the SD-card partition mounted read-only filesystem, have logging enabled, etc. I would not take that as a relevant reference for a proper audio player with read-only SD-card partition. Nevertheless an embedded device (unlike a PC) must be able to survive a repeated power cut, when no shutdown script is able to run.
Industrial-quality SD cards cost more than RPi itself, decent non-industrial models still fetch a substantial part of the BOM. IMO an SD card is not the best practice in an embedded device. That is why I am very glad the CM4 finally offers the eMMC option.
I have a pool of RPi's and a pool of SD cards that I have been using for over 6 years. I haven't thrown away any SD cards yet. No failures. I usually have 5 or 6 RPi's running at any given time.
Because of the "Corrupt SD card" issue that I read about I have one RPi that I just pull the power to turn it off each day. I have been doing this for years, and have had only one instance where music would not play after a boot. I couldn't determine the reason, and as I was experimenting with a beta release and testing the upgrade process I just reflashed it.
I feel neglected that I don't experience the issues that people report.
The original CM1 had an eMMC option, so its been around for many years.
Because of the "Corrupt SD card" issue that I read about I have one RPi that I just pull the power to turn it off each day. I have been doing this for years, and have had only one instance where music would not play after a boot. I couldn't determine the reason, and as I was experimenting with a beta release and testing the upgrade process I just reflashed it.
I feel neglected that I don't experience the issues that people report.
The original CM1 had an eMMC option, so its been around for many years.
Regarding the corruption I experiened, it was a system with a custom built Linux, which did not do any SDcard writing. There was no clean shutdown, just removing the power.
It led to SD card currption several times, with different SD cards. At that time there were many discussions on the internet about SD card corruption.
After this I moved to a BBB same conditions and never experienced any SD card issue.
There are different versions of the RPI and I remember to have read somewhere about an improvement to SD card corruption. The behaviour might be different based on power supply rise and/or fall times, which migh explain as well not everybody experiences this.
It led to SD card currption several times, with different SD cards. At that time there were many discussions on the internet about SD card corruption.
After this I moved to a BBB same conditions and never experienced any SD card issue.
There are different versions of the RPI and I remember to have read somewhere about an improvement to SD card corruption. The behaviour might be different based on power supply rise and/or fall times, which migh explain as well not everybody experiences this.
Last edited:
@phofman
Just did a bit of reading related to the CM4. I want indeed to design my own baseboard, so it seems an interesting option. I only have an Easy-pc license and do not use Kicad, but it should be not too difficult to layout the basics, which are mainly HDMI, ethernet and USB connectors. I only have to make sure to get the trace impedances and length matching right.
Probably with the CM4 there is a second I2S interface which I can use for an SPDIF input. Then the CM4 can function as a FIFO when passing the data to the DAC via the other I2S.
Just did a bit of reading related to the CM4. I want indeed to design my own baseboard, so it seems an interesting option. I only have an Easy-pc license and do not use Kicad, but it should be not too difficult to layout the basics, which are mainly HDMI, ethernet and USB connectors. I only have to make sure to get the trace impedances and length matching right.
Probably with the CM4 there is a second I2S interface which I can use for an SPDIF input. Then the CM4 can function as a FIFO when passing the data to the DAC via the other I2S.
The Broadcom SoC has only one PCM/I2S peripheral with one 2ch in and one 2ch out, shared clocks. SPDIF input is a clock master (PLL'd from the incoming stream). RPi could asynchronously resample between in and out clocks (I2S + USB would have to be used) but what would be the purpose of such FIFO?
The HDMI connector is in case I ever want to use it as a media player for video as well. (or some touchscreen display with user interface), So not related to the I2S audio.
Today I went through the CM4 manual and available I/O it had indeed only a single I2S peripheral. The purpose of the using the CM4 as a FIFO, would be to use the SPDIF data "as is", so without resampling. Feed it into the CM4 at SPDIF clock rate, where it is buffered and clock it out using MCLK via the I2S, where it synchonized to MCLK before the DAC, this completely eliminates SPDIF jitter and would provide the same quality as local FLAC playback (assuming there are no bit errors, I could not find anyone who did a BER test on an SPDIF link)
SPDIF specifies a clock accuracy < 1000ppm. For some worst case situation where the SPDIF clock is at one end and the DAC clock at the other end approx. 7 seconds of audio needs to be buffered for one hour playing time.
Just a rough idea and not on my priority list, since I have converted all my CD's to FLAC , which the the main playback purpose of this project.
Today I went through the CM4 manual and available I/O it had indeed only a single I2S peripheral. The purpose of the using the CM4 as a FIFO, would be to use the SPDIF data "as is", so without resampling. Feed it into the CM4 at SPDIF clock rate, where it is buffered and clock it out using MCLK via the I2S, where it synchonized to MCLK before the DAC, this completely eliminates SPDIF jitter and would provide the same quality as local FLAC playback (assuming there are no bit errors, I could not find anyone who did a BER test on an SPDIF link)
SPDIF specifies a clock accuracy < 1000ppm. For some worst case situation where the SPDIF clock is at one end and the DAC clock at the other end approx. 7 seconds of audio needs to be buffered for one hour playing time.
Just a rough idea and not on my priority list, since I have converted all my CD's to FLAC , which the the main playback purpose of this project.
7 secs buffering would mean 7 secs latency, including control (play/pause/stop). Would you bear with that?
The hardware FIFO solutions typically use several hundreds of msecs. Asynchronous reclocking is a workaround though, not a solution. Merging clock domains is always a compromise, even asynchronous resampling (ASRC) cannot eliminate the incoming jitter completely.
My choice would be a decent clock at the SPDIF source and ASRC at the sink if the sink has its own clock. IMO an industry standard solution.
The hardware FIFO solutions typically use several hundreds of msecs. Asynchronous reclocking is a workaround though, not a solution. Merging clock domains is always a compromise, even asynchronous resampling (ASRC) cannot eliminate the incoming jitter completely.
My choice would be a decent clock at the SPDIF source and ASRC at the sink if the sink has its own clock. IMO an industry standard solution.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.