Multichannel audio on a Pi will get a whole lot easier and cheaper!

[gordoste]

I don't know if it is related or not, but I modded a multichannel HDMI audio extractor to get 8 channel multiple spdif outputs from my RPI 4b via HDMI and I also had the channels messed up everytime there was a buffer underrun (I was using CamillaDSP). The only solution was to automatically restart CamillaDSP every time it happened.
I suspected the problem was the driver, but people more knowledgeable told me the driver was apparently fine...

This is exactly what is happening for me. I used a Suptronics X6000 HDMI extractor which has 4 stereo outputs. Channels get messed up frequently.

It is quite annoying that nobody can confirm that 8-channel I2S (BCK/LRCK + 4 pairs of I/O pins) works on RPi5. The pin mapping is listed in the RP1 datasheet but that is all.

 

[MCH]

This is exactly what is happening for me. I used a Suptronics X6000 HDMI extractor which has 4 stereo outputs. Channels get messed up frequently.

It is quite annoying that nobody can confirm that 8-channel I2S (BCK/LRCK + 4 pairs of I/O pins) works on RPi5. The pin mapping is listed in the RP1 datasheet but that is all.

hm, went straight away to see what hdmi transceiver chip your suptronics extractor uses and it is an Explore, not the same, but from the same family than the one my extractor uses. I keep on wondering if this is a fault of the chip, the driver, or who knows what...

If you want to have a look at how i fixed the issue (with the help povided by the gentleman in the post below ), you can start reading here:

CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

You need to make some changes to get things loaded on boot. I would recommend to use the alsa loopback, not a pipewire null-sink. Loopback kernel module: https://github.com/HEnquist/camilladsp-config#step-2-load-loopback-driver-on-boot Pipewire config...

www.diyaudio.com

 

[phofman]

It is quite annoying that nobody can confirm that 8-channel I2S (BCK/LRCK + 4 pairs of I/O pins) works on RPi5. The pin mapping is listed in the RP1 datasheet but that is all.

IMO the discussion with RPi devs confirmed the I2S0+1 8ch feature https://forums.raspberrypi.com/viewtopic.php?p=2148997#p2148925 . What remains to be confirmed is the MCLK IN/OUT which is important too for integration with quality codecs https://forums.raspberrypi.com/viewtopic.php?p=2159223#p2159223 .

 

[gordoste]

IMO the discussion with RPi devs confirmed the I2S0+1 8ch feature https://forums.raspberrypi.com/viewtopic.php?p=2148997#p2148925 . What remains to be confirmed is the MCLK IN/OUT which is important too for integration with quality codecs https://forums.raspberrypi.com/viewtopic.php?p=2159223#p2159223 .

Yes, it was already "confirmed" in the RP1 datasheet, but datasheets with DRAFT written across them or web forums aren't really enough - I don't believe it until it's tested or listed officially as a feature... it's the kind of thing where it SHOULD work, but who knows what kind of weird bug there might be. The comment from the dev in the first thread you linked "There can't possibly be compatible hardware that makes use of the additional channels available yet. Cart before horse." really annoyed me.
I hadn't seen your dedicated thread, thanks for pointing that out and raising the documentation issue.

 

[phofman]

I don't believe it until it's tested

Well, IMO all it takes to test is an RPi5 and an overlay which flips the other pins to the i2s function, like in https://forums.raspberrypi.com/viewtopic.php?p=2158110#p2156536 + using the rp1_i2s1_8ch in i2s_clk_producer and i2s_clk_consumer overlay.

I do not have any RPi5 to start with

 

[gordoste]

Well, IMO all it takes to test is an RPi5 and an overlay which flips the other pins to the i2s function, like in https://forums.raspberrypi.com/viewtopic.php?p=2158110#p2156536 + using the rp1_i2s1_8ch in i2s_clk_producer and i2s_clk_consumer overlay.

I do not have any RPi5 to start with

Yes, I'm in the same situation. I have built a whole system (including speakers) from scratch over several years and the channel-swapping is a dealbreaker. Multi-channel output over HDMI is a perfect example of something that "should" work but got impacted by a weird bug (most likely not RPi's fault in this case).
Up until now, I didn't really want to buy an RPi5 because it would require me to also finish designing and building a multi-channel DAC which will take several months - I'd be better to buy a USB soundcard to get the system working, even though that totally breaks my original design idea where RPi+HDMIextractor+amps are all in one chassis.
If the solution posted by @MCH works then I will be VERY happy as I can potentially call the system "done" (for now) and in that case, I might buy an RPi5 and continue working on the multi-channel DAC anyway (while listening to my system).

 

[gordoste]

Good news - initial testing appears to indicate that the solution works. Channels 7 and 8 on my system are monitors which are fed to an LED VU meter, and I have a gain filter on those channels to allow adjusting sensitivity and muting them (to turn off the VU meter). When the channels are messed up, muting those channels affects the sound (channels 1-6 are fed to amplifiers). I had the system running overnight and in the morning, the channels were messed up. Restarting camilladsp fixed it. Now I just need to set it up to happen automatically.

 

[phofman]

Ad Rpi5: https://github.com/raspberrypi/documentation/issues/3285#issuecomment-1894484173

 

[somebodyelse]

That's disappointing.

 

[phofman]

I wonder what the reasons are... I cannot imagine why they would want users to not use a useful feature which is a standard in all other ARM SoCs. Maybe there are bugs in the chip they do not want to disclose... I do not know. In any case there are other interesting full-featured SoCs to focus on.

 

[somebodyelse]

Not many with hardware timestamping on the ethernet port though - it would have been good to have an alternative to the Beagleboard for AVB.

 

[phofman]

I have not done any research, but e.g. RK3566, RK3588 do (if "Support Ethernet packet timestamping as described in IEEE 1588-2002 and IEEE 1588-2008 (64-bit timestamps iven in the Tx or Rx status of PTP packet). Both one-step and two-step timestamping is supported in TX direction" is the right feature). E.g. https://shop.allnetchina.cn/products/rock3-computing-module?variant=39486826741862 and many other RK3566/8 -based boards.

 

[Nisse10000]

I don't know if it is related or not, but I modded a multichannel HDMI audio extractor to get 8 channel multiple spdif outputs from my RPI 4b via HDMI and I also had the channels messed up everytime there was a buffer underrun (I was using CamillaDSP). The only solution was to automatically restart CamillaDSP every time it happened.
I suspected the problem was the driver, but people more knowledgeable told me the driver was apparently fine...

I think it is the driver, I get different behaviour with different drivers.

 

[gordoste]

I think it is the driver, I get different behaviour with different drivers.

Could you possibly provide details? I had the exact same problem as @MCH. Fortunately I can essentially eliminate buffer underruns (which are due to separate clocks on capture and playback streams) using adaptive sample rate conversion in CDSP, and any buffer underrun is automatically recovered by restarting CDSP.
Note that just because you get different behaviour using different drivers, that doesn't necessarily mean the driver has a bug. If both drivers output fully compliant HDMI signals that are slightly different and the extractor chip fails to handle one of them properly, then the bug is in the extractor. We need to find somebody feeding RPi HDMI multichannel audio to a surround sound system that uses a different HDMI receiving chip.

 

[gordoste]

Ad Rpi5: https://github.com/raspberrypi/documentation/issues/3285#issuecomment-1894484173

This is disappointing but it just means we need to either have the Pi function as a I2S clock consumer, or pick a chip that can function as a clock consumer and only needs BCLK fed in. Initially it was weird to me that any chips require MCLK to function as a I2S consumer, since MCLK is not part of the I2S standard (AFAIK), although it makes sense once you start designing the clock architecture.

 

[phofman]

MCLK signal is part of most I2S/PCM interfaces in ARM SoCs. Often bidirectional - the interface can accept external MCLK and does the internal division to master BCLK.

A codec with I2S only must either PLL the master clock (the cheaper ones do), or uses async resampling to local master clock (ESS). Typically codecs require MCLK.

But the ramblings at RPi forums https://forums.raspberrypi.com/viewtopic.php?p=2181897&sid=9b0ccc67d690c97cf51fe75efa00c403#p2181897 seem to revert the decision https://github.com/raspberrypi/documentation/issues/3285#issuecomment-1896674989

 

[ZolaIII]

It's not $/$ and sweat spot is still with two big cores and you will probably want to add bunch of storage and some paid software to your own.

With Pi you get limited regarding in generally IO.
Pi is a big shame of an ARM development board to a ironic point we get a big little on X64 and not on ARM while scheduler on ARM is much ahead of Intels implementation. The video core is a shameful part.

 

[gordoste]

Cool @phofman, great to see that persistence pays off. I am using one of the less expensive (but still quite decent) codecs. Out of interest, do you have any further info about drawbacks of using internal PLL to generate MCLK?

 

[phofman]

@ZolaIII : I agree. I feel that perhaps RPi is trying to position the board as a desktop replacement. But IMO it makes no sense to compete with the low-cost x86s. It must win on interfaces not present in x86 - and these are lacking compared to other ARMs.

On the other hand their RP1 chip is very unique. It packs lots of important features (some remain to be documented/drivers written) into a PCI-e x4 chip. Due to their production quantities they could afford an ASIC at probably very reasonable production price.

Recently I have been looking at PCI-e I2S options. Actually for other ARM SBCs, because while most SoCs have all the features, their SBC implementations always hide/reuse many pins. But all newer have PCI-e available (some even x4). The only chip still sourcable in hundreds is old CM8888 (also an ASIC) which has no implementation docs available, no go. All other options involve FPGAs which cost a lot if powerful enough to interface with PCI-e + require programming. One RP1 would solve it (along with the other useful features like several flexible PLLs etc). But the RPi people must be aware of that and almost certainly will not be selling the chip alone.

 

[phofman]

drawbacks of using internal PLL to generate MCLK?

Every PLL is worse than direct clock, some more, some less. But it may be (and likely is) perfectly fine in your usecase. Most likely inaudible, just precise measurements would tell.