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

[mdsimon2]

@MCH: IIUC that commit selects only I2S inputs and is not needed for the actual functionality. IMO just listing all relevant pins as in https://forums.raspberrypi.com/viewtopic.php?t=359494#p2156536 should enable the input too. I do not know if @mdsimon2 tested the inputs as mentioned in https://www.audiosciencereview.com/...-easier-and-cheaper.48233/page-5#post-1860961 , it may work just with that, if arecord -l lists the capture device.

I tested the inputs following these instructions (which are pretty much all based your guidance) -> https://www.audiosciencereview.com/...ole-lot-easier-and-cheaper.48233/post-1897977.

I used it with an AppleTV and a HDMI to I2S extractor for about a month but eventually experienced an issue -> https://www.audiosciencereview.com/...ole-lot-easier-and-cheaper.48233/post-1902674 and haven't since.

Michael

 

[phofman]

Michael, thanks a lot. That means the I2S input and output work on your setup, that static was probably some issue unrelated to the I2S setup/DTS/driver. No driver mods/kernel code is needed, just listing all the pins in the DT overlay.

 

[renne]

Hi guys,

In case someone was following, just wanted to make you aware that I am about to give up with the multichannel HDMI input hat project.
I designed and printed the PCBs, that I am very happy with and look great. I eventually made them 6 layers because JLCPCB offered to make them for free, but needed to be 6 layers, so I did signal/ground/power/signal/ground/signal.
View attachment 388622
Of course I made a couple of mistakes but fortunately I realized before finishing and could correct them with a couple of tiny jumpers (I used a footprint that was not correct for a couple of mosfets that interface the 5V HDMI SDA/SCL pins to 3.3V of the extractor chip), as you can see in the picture close to the input connector.
View attachment 388620View attachment 388615
These are the hats partially populated, but that should be functional.
Definitively this is not a project for a first time soldering SMD, there are 0402 parts and the main chip has 128 pins, but if you have some practice is perfectly doable:

What happened then? Well, it does not want to boot up. I am almost certain it is a problem with the internal MCU, that somehow got its program corrupted. I read in the internet that programmed chips can survive soldering but the problem here is that you need to heat A LOT the chip to desolder it from the donor board, as the PCB itself is very big with ground pours and unleaded solder…. I am pretty sure that the chip got damaged at that stage.

What happens is that when I power the board, all the LEDS light (like in the original device), but stay lite (unlike the original device). Additionally, 12MHz the master clock signal is not there, unlike in the original device where it is always present, and the i2s signals don’t show up when they should. The only other external signal that measures different to the original device is hto_ctlb (no idea what that means) that should go low to activate a mosfet that turns HEAC- low (if I bring that pin down manually nothing changes). Other than that, all power pins have power and there are no bridges or bad contacts in any of the 128 pins, that I checked one by one…. :-/

Fortunately I spent next to no money in this project, as I reused all the parts except the crystal, but I did spend a lot of hours on it, so I will leave it in the drawer for a while. If I ever come across one of these extractors for a good price, I might buy one and try to desolder the chip differently, with some of that liquid metal or just cutting the PCB so that the thermals are more favorable, but I don’t want to risk burning another IC....

@MCH

As far as I know HDMI-eARC is not HDCP-protected.
A SiI9437 + 2x TI SRC4194 in asynchronous hardware-mode should do the trick if you can live with the limitation to connect it only to an eARC-capable TV. The SiI9437 cannot handle standard HDMI from players. This setup also needs a MCU (or RPi) to set the EDID in the SiI9437 via I²C and an OpenDrain-GPIO for HDMI-CEC.
If you add a Coolaudio V1401-transceiver you get ADAT-Lightpipe for USB-audio-interfaces. ;-)

 

[stigger]

As far as I know HDMI-eARC is not HDCP-protected.
A SiI9437 + 2x TI SRC4194 in asynchronous hardware-mode should do the trick if you can live with the limitation to connect it only to an eARC-capable TV. The SiI9437 cannot handle standard HDMI from players. This setup also needs a MCU (or RPi) to set the EDID in the SiI9437 via I²C and an OpenDrain-GPIO for HDMI-CEC.
If you add a Coolaudio V1401-transceiver you get ADAT-Lightpipe for USB-audio-interfaces. ;-)

Is the Sil9437 datasheet available somewhere? On their website there is only a short product brief.

 

[rthorntn]

just listing all the pins in the DT overlay.

This is a great thread and it has made me think, I have somehow managed to find myself in the position of having two dead USB DACs, a minidsp U-DAC8 and a ifi micro iDSD, I'm fairly certain the culprit is the XMOS (the ifi works fine through SPDIF).

Both the ifi and minidsp have the XMOS on a daughtercard, in the minidsp's case its a standalone product, the USBStreamer and the manual clearly shows the J1 pinout uses I2S:

#1 - I2S data OUT ch1&2
#2 - I2S data IN ch1&2
#3 - I2S data OUT ch3&4
#4 - I2S data IN ch3&4
#5 - I2S data OUT ch5&6
#6 - I2S data IN ch5&6
#7 - I2S data OUT ch7&8
#8 - I2S data IN ch7&8
#9 - MCLK OUT
#10 - SCLK
#11 - GND
#12 - LRCLK

So to the thought, with the U-DAC8, the RPi5 has "quad" I2S right so would it be trivial for me to salvage this DAC by using a RPi5 in place of the XMOS?

I know these DACs aren't great and I could just get a DAC8X to save myself the hassle bit I like re-purposing.

The ifi has a 36-pin PCIe style connector connecting the XMOS card, goes to 32/768 and so I'm guessing that this somehow uses multiple I2S channels stitched together, Ill approach this beast later.

Thanks.

 

[gordoste]

How will you generate MCLK for the U-DAC8?

 

[rthorntn]

Thanks, no idea, I'm new to all this I2S stuff but I found this:

RP1 could be configured to output the MCLK clock used for the I2S interface.

Or maybe an external crystal on a breakout board, not sure.

 

[phofman]

Or maybe an external crystal on a breakout board, not sure.

I2S clocks and MCLK must be synchronous, they can't be generated separately. You can either generate MCLK + the divided I2S clocks externally (e.g. using a clock circuit like Si5340D) and switch RPi5 I2S interface to slave, or generate MCLK externally and switch the RPi5 I2S mclk to be fetched from an external pin, or use the internally generated mclk for I2S and output this mclk to an external pin. The two latter options require setting up RPi5 in a way which has not been documented by RPi team yet. You can renew the discussion abandoned by the RPi devs at https://forums.raspberrypi.com/viewtopic.php?t=365761#p2238649 .

This feature (apparently supported by the HW and standard on other SoCs/SBCs) is long overdue as it seriously hampers the RPi5 audio capabilities. But since most people use DAC chips which suboptimally PLL the mclk from I2S bitclock (e.g. PCM5102 on the DAC8X hat), nobody cares much.

 

[rthorntn]

You can renew the discussion abandoned by the RPi devs

Thanks Pavel, that's so frustrating, I can see all your investigative work, thanks for doing that, its mega helpful to the less talented tinkerers!

Are there any other SBCs that have usable quad I2S and MCLK?

I guess I could try to shoehorn an MCHStreamer or maybe the diyinhk XMOS multichannel interface in there but using an SBC w/USB gadget would have been nicer as adding new inputs, streaming and DSP is then all nicely integrated.

 

[phofman]

I have tested a few other SBCs with multichannel I2S, they all support the MCLK I/O feature. But it's definitely not as simple to configure and make running as RPi5.

IMO the way to go is to put more pressure on RPi devs, via their forum and github issues https://github.com/raspberrypi/documentation/issues/3285

 

[MCH]

But since most people use DAC chips which suboptimally PLL the mclk from I2S bitclock .

I guess it belongs to DACs 101, but can you explain why pll is suboptimal for real use case? I read this often but I never understood it. Also,

 

[rthorntn]

But it's definitely not as simple to configure and make running as RPi5

Thanks, do you mean it's harder to get a distro on them, maybe kernel rebuilds?

That stuff is fine for me as I have decent Linux experience, coding is where I hit a wall.

 

[phofman]

why pll is suboptimal for real use case?

PLL will by principle produce higher jitter that a fixed crystal-based clock. That's why I call it suboptimal. A precise measurement will show the difference. Is the difference audible? Probably not.

But there are many other DAC chips without the internal PLL block and these need the MCLK signal.

That clock signal is available in RP1 and the hardware is capable of outputting the clock directly. Or the other way round, if some mclk signal is already available - the mclk clock for the RP1 I2S interface can be sourced from a pin switched to input. It's "just" about configuring RP1 correctly which only RPi people know how to do.

 

[gordoste]

PLL will by principle produce higher jitter that a fixed crystal-based clock. That's why I call it suboptimal. A precise measurement will show the difference. Is the difference audible? Probably not.

But there are many other DAC chips without the internal PLL block and these need the MCLK signal.

That clock signal is available in RP1 and the hardware is capable of outputting the clock directly. Or the other way round, if some mclk signal is already available - the mclk clock for the RP1 I2S interface can be sourced from a pin switched to input. It's "just" about configuring RP1 correctly which only RPi people know how to do.

What are the disadvantages of putting RPi in I2S slave mode and using a crystal?

 

[phofman]

None, technically it's the preferred way. But you need to have all I2S clocks generated externally, i.e. either two dividers (bitclock, frameclock), or one of the codecs running in master I2S mode and generating the I2S clocks.

 

[gordoste]

None, technically it's the preferred way. But you need to have all I2S clocks generated externally, i.e. either two dividers (bitclock, frameclock), or one of the codecs running in master I2S mode and generating the I2S clocks.

Glad I wasn't missing something!