The RPi series is known to be problematic wrt heavy USB I/O, although there are workarounds which can help. The Pi 4 might be better.

Probably a better solution is to use an inexpensive DSP chip for summation of multiple I2S sources with programmable gain. Scale the DSP according to the serial inputs required.

gdjacobs wrote on 2020-07-01, 15:59:

The RPi series is known to be problematic wrt heavy USB I/O, although there are workarounds which can help. The Pi 4 might be better.

Probably a better solution is to use an inexpensive DSP chip for summation of multiple I2S sources with programmable gain. Scale the DSP according to the serial inputs required.

I have no doubts that the DSP approach is better, though beyond my essentially non existent skills in the fields of hardware design and programming (with th exception of some shell scripting).

I do, however, have a spare Pi 4 looking for a purpose . Again, if my programming skills were better, running I2S over the GPIO pins (if fast enough) would be something I would consider (ready made S/PDIF to I2S receivers are easy to source).

The Pi4 + USB S/PDIF approach is, unfortunately, the only one within my reach . Thanks for confirming my worries about USB I/O . If I could find some cheap S/PDIF to USB receivers, I would still likely give it a shot. Even if I fail miserably, the learning experience would be worth it .

You can find cheap USB analog audio dongles on eBay. Even if they don't work for your final product, you'd be able to generate the kind of expected I/O load and prove the concept.

You probably could capture additional channels of I2S directly through the GPIO pins instead of via the two I2S channels, but I'm not sure how far you could scale it. The Pi boards have less efficient I/O than many other embedded SoCs.

gdjacobs wrote on 2020-07-01, 19:24:

You can find cheap USB analog audio dongles on eBay. Even if they don't work for your final product, you'd be able to generate the kind of expected I/O load and prove the concept.

You probably could capture additional channels of I2S directly through the GPIO pins instead of via the two I2S channels, but I'm not sure how far you could scale it. The Pi boards have less efficient I/O than many other embedded SoCs.

I was hoping to actually find some USB S/PDIF input dongles first, because if I can't find those at reasonable prices, the concept really is not feasible to begin with . To reduce USB I/O contention, I could use an HDMI S/PDIF audio extractor for output (I think I have spare one lying around) instead of an additional USB output device .

My goal is 3 or 4 inputs . That seems within reach of even USB 1.1, in theory .

darry wrote on 2020-07-02, 17:33:

My goal is 3 or 4 inputs . That seems within reach of even USB 1.1, in theory .

Assuming you're not restricting sampling rate or bit depth, you'll need 196608 /s sample rate * 24 b sample bit depth * 2 channels per I2S port for a grand total of 9437184 b/s per I2S port. Looking at Aliexpress, it seems 15 USD per stereo channel might be doable.

gdjacobs wrote on 2020-07-02, 19:11:

darry wrote on 2020-07-02, 17:33:

My goal is 3 or 4 inputs . That seems within reach of even USB 1.1, in theory .

Assuming you're not restricting sampling rate or bit depth, you'll need 196608 /s sample rate * 24 b sample bit depth * 2 channels per I2S port for a grand total of 9437184 b/s per I2S port. Looking at Aliexpress, it seems 15 USD per stereo channel might be doable.

I wasn't planning on anything beyond 48KHz at 16bit sample depth, but that's a very good point. If I am not mistaken, S/PDIF zero-pads 16bit to 24bit so I probably need to consider 24-bit as a minimum for bandwidth calculation .

I was considering some of these CM6206-LX based USB "sound cards" https://www.amazon.ca/Optimal-Channel-Externa … r/dp/B00Q4WQ7XW .

The CM6206-LX is USB 2.0 "full speed" (basically USB 1.1 "high speed"), so I was thinking of running them through a multi-transaction translator USB 2.0 hub, if I can find one.
See https://www.tomshardware.com/reviews/usb-tech … logy,677-3.html (this is dated, but I imagine it still applies) .

Pretty sure that's what the ones on Aliexpress are using. Likely your best bet, although I haven't messed with SPDIF input to know how solid that is with those parts. I've got one on hand, so it's maybe something to do tonight...

I ordered a multi TT USB 2.0 hub and two of those USB SPDIF sound cards, for starters. For SPDIF output, I have a UCA202 already . I will begin putzing around with the PI when I get the chance.

If all this amounts to nothing useful, I should still find a use for the hub and only be out a few dollars for the USB sound cards .

Well, I tried to advance this project.

Observations :
a) Even with the latest firmware for the Via VL805 USB 3.0/2.0 hub integrated in the Pi 4 (latest firmware fixes an issue with similar symptoms), I cannot connect even 2 full-speed USB audio interfaces to any two ports on the Pi 4 without getting a crap-ton of these in dmesg

1[Thu Feb 18 17:51:15 2021] usb 1-1.4.6: Not enough bandwidth for new device state.
2[Thu Feb 18 17:51:15 2021] usb 1-1.4.6: Not enough bandwidth for altsetting 3
3[Thu Feb 18 17:51:15 2021] usb 1-1.4.6: 1:3: usb_set_interface failed (-28)

b) The symptom in "a" affects cheap CM106 USB devices (I have 3 of those) and Fiio E10K ones (I have 2 of those) in any combination as long as there are 2 or more connected
c) Connecting 2 or more of the those devices through a Plugable branded multi-TT USB (confirmed in lsusb) gives the same results whether connected to one of the Pi 4's USB 2.0 or USB 3.0 ports
d) Symptom "a" is present in the latest 32-bit build of Raspbian and also in the latest 64-bit build of Ubuntu
e) As a test, connecting 3 of the CM106 USB devices through the multi-TT USB hub into a USB 3.0 port on a Gigabyte B450 I AORUS PRO WIFI running Buster shows no issues .

Tentative conclusion so far : the USB subsystem of the Pi 4 does not seem to shine when using "high bandwidth" USB 1.1 devices . Whether this is a software, firmware (VL805) or hardware (VL805), I do not know, but I guess I will try reporting it and hope for the best . I am disappointed, to say the least . On an unrelated note, but also frustrating note, I was unable to get h.264 video acceleration to work satisfactorily on Youtube using Chromium or Firefox (says it's enabled and in-use, but CPU usage is through the roof and video skips/stutters), though it does work fine with the custom build of VLC included with Raspbian (with specific patches not in mainline VLC). I am glad that I am not trying to build a streaming media player .

Plan B :
The Raspberry PI 4 Broadcom SOC has an integrated USB 2.0 host controller that is not enabled by default, but can be set to host mode, and is physically exposed through the Pi's USB-C power input connector . I ordered a USB-C hub which supports USB power delivery and the required PSU and am going to hope that I can
a) get that USB controller to work
b) successfully attach at least one USB audio devices to that host controller, ideally 2 or 3 (using my multi-TT USB hub in between, if necessary/useful)
c) If I can only get a total of 2 USB audio devices working, get an an HDMI audio to S/PDIF de-embedder and try to use that as an output .

Plan C:
Chuck the Raspberry Pi 4 as far as I can throw it and use SFF x86/x64 PC instead .

Thanks for reading my cathartic rant . 😉

In the amateur radio VHF/UHF repeater community, the Pi 4 is known to have issues with multiple C-Media dongles connected via USB. Pi 3 has no such problems beyond previously known raw performance limits.

gdjacobs wrote on 2021-02-19, 08:22:

In the amateur radio VHF/UHF repeater community, the Pi 4 is known to have issues with multiple C-Media dongles connected via USB. Pi 3 has no such problems beyond previously known raw performance limits.

It seems to work!!! I only had time for a quick test so far, butI have 3 CM106 like devices on a multi TT UB 2.0 hub plugged into my new USB-C 3.0 hub with USB PD. The USB-C 3.0 hub with USB PD is powering the Pi 4 over its USB-C connector and is exposing 3 USB ports connected to Broadcom SOC integrated USB 2.0 controller . No more bandwidth errors!!!

On the Via VL805 managed USB 2.0 and USB 3.0 ports, I can't even have a keyboard and mouse plugged it at the same time as Fiio E10K or only 2 Fiio E10Ks or only two CM106s without getting bandwidth errors .

At least on my Raspberry PI 4, there is something very off about USB 1.1 support, even when used through a multi TT hub .

I will run more tests, but if my approach is successful, it could also be a workaround for the VHF/UHF repeater community .

Another day, another "interesting" bug .

First the good news. Using the setup described in my previous post does indeed seem to work fine in terms of USB bandwidth. The ultimate test will come when I actually have 3 incoming streams and one outgoing one simultaneously over USB, but that will be for another day .

The other snippet of good news is that ALSA and jackd seem to work fine with 16-bit word length at both 441.KHz and 48KHz in Raspbian on my Pi 4

However, if I try outputting anything at 24-bit/44.1KHz , I get static with some barely audible music in the background . If I choose any other sample rate (32KHz, 48KHz, 96KHz) at 24 bits, everything works fine . If I force 16-bit mode in jackd , 44.1KHz works fine too . So it is only the 24-bit/44.1KHz combination that does not work properly . I have reproduced this with 2 different USB sound cards (Fiio E10K and Roland UA4FX). My initial testing was with VLC using the jack plugin and with resampling disabled . Format is S24_3LE in all 24-bit modes, if anyone is interested . EDIT : I used audio files with appropriate word length an sample rate for all tests .

I then moved on testing with aplay and was able to reproduce the issue immediately , so it is not a jack issue, but an ALSA related one . Finally, I decided to try the E10K with aplay on a current Debian x64 machine running the same version of ALSA as the Pi 4 and it worked fine on the first try ! EDIT: at 24-bit and 44.1KHz .

Next step is to try it on Ubuntu running on the Pi 4 . If that does not work, I will have to stick to 48KHz at 24 bits for output .

The reason I want 24-bit output is the avoid clipping on the off chance the 3 S/PDIF inputs were to peak at the same time . If my math is correct, 3 16-bit sources at peak, added together, would require a bit less than 18 bits in order to avoid clipping .

If anyone is curious, I plan to get around the fact that the input clocks and the output will not be in sync and not necessarily have the same sample rate by using zita-ajbridge between a jackd output device and ALSA hardware inputs . The plan is then to use a software mixer like jackmix (or something similar) .

EDIT : Same problem in Ubuntu 64-bit on Pi 4 . Using ALSA, S24_3LE at 44.1KHz is broken, but S24_3LE at 96 KHz, for example, works fine . Again, S16_LE works fine at 44.1KHz .

EDIT2 : Corrected typos, I meant S24_3LE not S24_LE

EDIT3 : The USB bandwidth issue and workaround (using the integrated USB 2.0 controller) are described here https://github.com/raspberrypi/linux/issues/3962

IT WORKED!!!

I was able to mix two S/PDIF sources at two different sample rates (44.1KHz and 48KHz) without a common word clock using the resampling functionality in zita-ajbridge and using jackd on my Fiio E10K for output. The sound quality was subjectively transparent to me and there were no glitches or dropouts during preliminary testing (i used music from Doom and and a 1 KHz test tone, first alternatingly and then simultaneously) . I did not even use jackmix, I just connected both my sources to to the output using qjackctl . If this also works for three sources, I may not even bother with jackmix . I did not notice any added latency .

TODO :

- Add a third USB S/PDIF input device to the mix and see if I hit USB bandwidth or CPU limitations (I should have checked CPU load while it was running).
- Reproduce what I do in qjackctl using the CLI . EDIT: Done
- Add jackmix (optionally and if actually useful, might come in handy to control relative volume of sources centrally) EDIT : I tried jack_mixer, and it works fine . It is tempting to get an touchscreen too . EDIT: Touchscreen is on the way as it was way cheaper than a MIDI control surface . EDIT : Touchscreen is installed and working fine as a screen but sucks on the touch aspect. A cordless mouse and USB keypad will do the trick .
- Find a way to do some quality tests (essentially running some subjective tests, testing with udial.wav and possibly running some easy to do tests if someone can suggest some).
- Assuming everything works as expected, document how to do this in greater detail, for my own notes and in case somebody else is interested