RPI or Rock64 I2S with external MCLK - Page 2

phofman · 13th January 2021, 06:26 AM

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.

Greg Erskine · 13th January 2021, 07:02 AM

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.

phofman · 13th January 2021, 07:26 AM

Greg, good to hear a different experience. I guess the average experience will be somewhere in between. What OS do you run and what SD card type do you use? Thanks.

Greg Erskine · 13th January 2021, 01:16 PM

piCore/piCorePlayer or Raspbian (aka RPiOS)

SanDisk

output · 08:00 PM

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.

output · 13th January 2021, 08:07 PM

@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.

Markw4 · 13th January 2021, 08:55 PM

Isn't HDMI LVDS, not LVCMOS? If so, wouldn't I2S signals have to be converted so they could drive a cable?

phofman · 13th January 2021, 09:36 PM

Quote:

Originally Posted by output

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?

output · 14th January 2021, 10:04 PM

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.

phofman · Yesterday, 07:39 AM

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.

13th January 2021, 07:02 AM	#12
Greg Erskine piCorePlayer diyAudio Member Join Date: Jan 2002 Location: Sydney/Australia	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. __________________ Greg Erskine

13th January 2021, 01:16 PM	#14
Greg Erskine piCorePlayer diyAudio Member Join Date: Jan 2002 Location: Sydney/Australia	piCore/piCorePlayer or Raspbian (aka RPiOS) SanDisk __________________ Greg Erskine

13th January 2021, 07:56 PM	#15
output diyAudio Member Join Date: Oct 2016	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. Last edited by output; 13th January 2021 at 08:00 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
STA350B I2S, MCLK question	Strags	Digital Source	3	8th January 2021 06:59 PM
Using WM8804 with 3-wire I2S (no mclk input)?	matdogg	Digital Line Level	6	14th October 2018 09:00 PM
Using WM8804 with 3-wire I2S (no mclk input)?	matdogg	Digital Source	0	18th November 2017 12:52 AM
External LiPo cell for RPI 3	Eldam	PC Based	24	1st August 2016 11:54 PM
What pin has I2S MCLK output on mini2x4	poolorpond	miniDSP	0	18th September 2014 09:30 PM

New To Site?	Need Help?
Register to Participate Privacy Statement Contact Us	Frequently Asked Questions Did you forget your password? Mark Forums Read


	Please consider donating to help us continue to serve you. Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving

13th January 2021, 06:26 AM	#11
phofman diyAudio Member Join Date: Apr 2005 Location: Pilsen	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.

13th January 2021, 07:26 AM	#13
phofman diyAudio Member Join Date: Apr 2005 Location: Pilsen	Greg, good to hear a different experience. I guess the average experience will be somewhere in between. What OS do you run and what SD card type do you use? Thanks.

13th January 2021, 08:07 PM	#16
output diyAudio Member Join Date: Oct 2016	@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.

13th January 2021, 08:55 PM	#17
Markw4 diyAudio Member Join Date: Jul 2016 Location: California	Isn't HDMI LVDS, not LVCMOS? If so, wouldn't I2S signals have to be converted so they could drive a cable?

14th January 2021, 10:04 PM	#19
output diyAudio Member Join Date: Oct 2016	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.

Yesterday, 07:39 AM	#20
phofman diyAudio Member Join Date: Apr 2005 Location: Pilsen	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.