Good point, two answers. First: because it's fun, and having multiple channels out of a sub €20 euro SBC like the Zero 2 coupled with a sub €5 like the Pico is enticing. Second: all the SBCs that support multichannel audio on paper seem to have issues when actually trying to make them work. The RPi5 does not support multichannel audio on paper (by the datasheet, I mean), I do not know of recent developments finding a way to achieve that somehow, there are lengthy threads on various forums but I've not seen a canon solution (but I also admit of getting tired after the fist few pages of the threads). But the RPi5 is far too expensive anyway, so...
I did not check the Radxa Pi S (I gave a look at the Rock 3c, actually), I do not understand your reference to the USB max current, are you suggesting some kind of USB-I2S solution? But in general, if you know about a cheap SBC that actually supports multichannel audio, I'd be glad to hear from you.
Progress report: kernel patched (the old patches by @olo111 do not work anymore, but provided a good staring point) and I2S@384k works just fine on the Zero 2, by my limited testing. Now I'm waiting for the Pico to arrive and we'll see if 1 I2S @384k -> 2 I2Ss out @192k is indeed possible.
I did not check the Radxa Pi S (I gave a look at the Rock 3c, actually), I do not understand your reference to the USB max current, are you suggesting some kind of USB-I2S solution? But in general, if you know about a cheap SBC that actually supports multichannel audio, I'd be glad to hear from you.
Progress report: kernel patched (the old patches by @olo111 do not work anymore, but provided a good staring point) and I2S@384k works just fine on the Zero 2, by my limited testing. Now I'm waiting for the Pico to arrive and we'll see if 1 I2S @384k -> 2 I2Ss out @192k is indeed possible.
Indeed, RPi5 can output up to 8 channels.
So you want to feed 2ch digital via USB, do DSP on RPi and then output 4 channels?
Just FYI, York can do that thru one usb, up to 384kHz for 4 output channels: https://www.diyaudio.com/community/...tichannel-input-output-interface-york.413504/
Good to know. As written in my previous message I kinda got lost among the various threads on the topic. If you can share a specific pointer to a post/thread addressing the issue I'd be grateful. That been said, again, the RPi5 is overkilled for what I need to do.
That's right. I guess I might add lossless bluetooth later, but for now: USB it is.
Yes, I know. But the ultimate goal is to have a smartphone room correction app that sets up the filters to be used, so I need more control on the DSP stuff and a way to remotely update the filters from the app. Which means I need the RPi.
I see. There is some discussion:
https://www.audiosciencereview.com/forum/index.php?threads/8ch-hifiberry-hat-dac-for-rpi5.53672/
Yes, the RPi will be needed anyways. That is just an interface, not DSP.
How do you plan the app implementation?
Yes, it's way too expensive and power hungry for a USB-multichannel I2S bridge with some reasonable DSP capabilities.
E.g. https://www.audiosciencereview.com/...d-direct-vs-any-dac.55386/page-6#post-2024214
https://shop.allnetchina.cn/products/rock-pi-s?variant=32279981490278
Many non-RPi ARM SBCs support proper 8ch audio, some 8+ch.
Basically a simpler version of https://housecurve.com/ (stealing code here and there from Open Sound Meter) that can upload the filters to the RPi. But that is a very long shoot from where I'm at now, if I was retired that could be achievable in a reasonable amount of time...
However, the rest of the setup (minus the app, I mean) is actually achievable.
Thanks. I see your chain includes a "I2S out @384/32/16ch" step. Is that an I2S/TDM signal available on some header pin? Have you been able to activate it with just some DT fiddling or is it more work than just that?
Update: I see here https://wiki.radxa.com/RockpiS/hardware/gpio that there are exposed GPIO pins for I2S0_8CH, which is great. But the overlays published on the same pages do not include anything I2S related...
Many non-RPi ARM SBCs have horrible support, with producers publishing kernels patched by copycatting code from around the net. I spent my spare time of the last week trying to make the I2S out of an OrangePI Zero 3 work.
At the end I've been able to do it (minus MCLK that I couldn't fix and that I needed). But I had to patch the kernel, mess up with the DT, all to get back to where I stated from with the RPi Zero 2 which, at least, has a community that can help...
Last edited:
Yes, but the S version outputs/inputs only 8ch. The S core module has all 24 I2S I/O channels available.
DTS is standard method of ARM kernel configuration, no way to avoid that. I have also modified kernel (e.g. raised samplerate limits to test real capabilities of the I2S interface) but that's not required.
Yes, if the feature is actually documented. In fact the level of detailed documentation for RPi is way below many of ARM boards which often have complete schematics and detailed SoC technical specifications available. Yes, it takes kernel effort to make features work as required, it's normal.
DT fiddling is expected. The point is: are the DTSs available or it's a work of patching up various almost-but-not-fully working versions popping out in forums and github repos?
I have my eyes on the Zero 3W now, it should have three I2S devices available, that would mean I could also input one I2S from a bluetooth adapter. If only I was sure that the DTSs to enable the three I2Ss and the USB UAC input are easy to find... I will ask on their forum, we'll see if they know their own stuff.
Since I need mainline latest for driver development, my situation was always much more complicated. But if you want only working features, it's typically not that difficult and radxa-provided kernels require only DT overlays. Also their forum is quite active, I use it quite often.
Typically if multiple interfaces are needed, the core boards are required (RK3566 is very popular and many SBC vendors have a number of core variants with RK3566). Core boards have many pins, of course require a custom IO board (but that's expected if a complex solution is being developed).
Hm, did you look at Zero 3W schematics? I cannot find 3 complete I2S interfaces being available on the SBC pinheader - one hooked to the internal BT chip (do you need your own?), another hooked to the internal codec. But I did not study the schematics thoroughly.
Typically if multiple interfaces are needed, the core boards are required (RK3566 is very popular and many SBC vendors have a number of core variants with RK3566). Core boards have many pins, of course require a custom IO board (but that's expected if a complex solution is being developed).
LOL I was naive enough to think "I see references to three I2S interfaces in the pinout description, they will surely have all signals available, otherwise why mentioning them?".
That's the advantage of complete documentation - the SBC schematics together with RK3566 technical specifications (thousands of pages, not like in RPi) - you can check anything. Site https://dl.radxa.com/ is quite unique, IMO.
I'm not myself a big fan or RPi's stuff but, taking the Zero 2W I'm working on as an example, the schematics are available (https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-zero-2-w) as well as the SOC Datasheet (directly from Broadcom).
On the contrary, I'm having a lot of issues on the software side of things with Allwinner's SOCs. Maybe Rockchip is better in this regard.
SBCs manufacturers really just "dress up" distributions with a small personalization layer on top of SOCs' makers "official" kernel distributions...
On the contrary, I'm having a lot of issues on the software side of things with Allwinner's SOCs. Maybe Rockchip is better in this regard.
SBCs manufacturers really just "dress up" distributions with a small personalization layer on top of SOCs' makers "official" kernel distributions...