[Pi4B] Can't use USB soundcards simultaneously. Works on Pi 3. #3962
Comments
biasha2
changed the title
|
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=273027 There is a limit of a maximum of 1023 bytes of periodic full-speed data per frame on Pi 4's VL805 USB controller. Your two audio devices have a single Isochronous endpoint alternate setting of 588 bytes (and frame interval of one frame), so you can't use both at once. A workaround is to use the USB-C connector's OTG functionality in xHCI host mode. You will need a USB-C hub, preferably one with power-delivery, that acts as an in-line breakout. One like this, for example: https://www.amazon.co.uk/UGREEN-Aluminum-Pass-Through-Thunderbolt-Compatible/dp/B077FSBGQK/ Alternatively, power the Pi 4 through GPIO pins and use a USB-C to USB Type-A adapter, then plug a regular USB2 hub into the adapter. |
|
Thank you for the explanation. So,
The proposed workaround does not really work for me: For now I transfer sound via ethernet to the Pi3. And Pi3 can easily handle 5 soundcards that I have. With any hub for 5th... It's just odd and sad :( |
|
The workaround isn't working because your hub is incorrectly detected as a full-speed hub (not high speed). |
|
The workaround indeed works after rpi-update (tested with usb3 hub). However as I said, powering though GPIO is hard for me because of the hat. And seems that 3 ampere usb data y-cables don't exist. Thank you for the workaround anyway. But is it going to be addressed in a proper way somewhen? What is the answer to my question above - #1, #2 or #3? |
|
Some time ago we raised this issue with Via and this resulted in a firmware (0138a1) that moved the FS periodic bandwidth cap from 792 bytes/frame to 1024 bytes/frame. There is likely to be an underlying hardware limitation due to the way FS period transactions are scheduled. The controller doesn't support the XHCI CHECK_BANDWIDTH command. Calculating bandwidth requirements in software will just replicate the checks done by the XHCI firmware. |
I use a USB 3.1 hub with USB PD (power delivery) support over USB-C that successfully powers the Pi 4 . The USB 3.1 hub has 3 USB A ports and is powered by a 30W USB PD power supply . I believe the USB PD power supply is only actually capable of providing 3A when outputting 5V (I doubt this USB 3.1 hub can actually run on anything other than 5V ). If my assumptions are correct, the the USB 3.1 HUB and Pi 4 are sharing 5V at a max of 3A and seem to be working fine, power-wise . Ironically the USB 3.1 hub has a Via chipset . The next part of my USB setup is an externally powered USB 2.0 multi-TT (transaction translator hub), which, AFAIK, is important if one wants to run multiple full bandwidth USB 1.1 devices over USB 2.0. This multi-TT USB 2.0 hub is connected to the aforementioned USB 3.1 hub that powers the Pi4 . Finally, I have 3 USB 1.1 "CM106 like" devices (probably actually CM6206 variants) and a Fiio E10K (also USB 1.1) connected to the multi-TT USB 2.0 hub . I have tested the behavior of this setup with simultaneous 3-way USB 1.1 traffic (2 16-bit stereo streams at 44.1KHz and 48KHz being recorded and one 24-bit 48KHz stereo stream being played back), so far, I am not getting any USB bandwidth errors or apparent bandwidth related audio glitches . PSU : RAVPower RP-PC144 EDIT : My Pi 4 is a rev 1.2 which has the issue with USB PD fixed, AFAIK . |
|
I have the same issue. I would also like to run 4 USB soundcards on a Raspberry Pi 4B and play continuously mp3 music. Or does anybody have another solution for this behavior? |
|
I have tried to use three 2.0 USB Hubs with one sound card plugs in the first port of each hub. The remaining USB port of Raspberry Pi 4 is connected with one sound card using direct plug in method. Turns out it unexpectedly works well and perfect. I am able to control each sound card and play simultaneously even though the "dmesg" still showed the error "usb_set_interface failed (-28)". Not sure how does it work, I assume that the USB hub actually has used certain amount of bandwidth so each port will not share the bandwidth. |
|
I'm getting this same failure on a brand new Pi 4B 8GB:
After connecting 2 or 3 USB sound devices, connecting an additional sound device triggers a stream of "Not enough bandwidth for new device state" in Things I've tried after reading and re-reading this github issue, the forum thread about this issue from 2020, and the forum thread about the firmware update from 2020:
I'm developing an audio gadget, so the USB-C port is in OTG mode and I'm unable to use it as an additional host mode port. I don't fully understand the issue here; for some people the firmware update back in 2020 seemed to solve their problems. I don't think biasha2 got an answer about whether it's is a hardware issue or a firmware issue. So, is this solvable, or is it a permanent USB limitation on all Pi 4s? What is the limitation? I thought it was that each transaction translator has a chunk of bandwidth to split between full-speed devices, and the onboard single-TT VL805 quickly exhausts itself after one or two audio devices. I thought a multi-TT hub was supposed to wrap each device in its own partitioned bandwidth pool. That doesn't seem to be happening, or maybe there's a bug in the VL805's bandwidth prediction that's not taking multi-TT hubs into account? Would a CM4 in a carrier board with a multi-TT hub chip behave any better? Here are my
|
I had the same issue you do and tried pretty much the same things you did before giving up on the VL805 and USB 1.x full speed devices . One possible workaround might be to use USB 2.0 high speed (or faster) devices . I presume that you are using USB 1.x full speed ones. As for the CM carrier board, AFAICR, it does not have a discrete USB controller (VL805) and neither does the compute module itself, so the only USB controller is the one integrated into the Pi SOC . However, the CM carrier does have a PCIE slot, so you might be able to use a different USB controller on a PCIE add-in card, which might work better. See https://pipci.jeffgeerling.com/#usb-cards for possible options . |
Yeah, even the audio devices I have that enumerate as USB 2.0 are still full-speed, not high-speed. I have half a dozen of them: a $5 junk adapter, a brand-new Apple USB-C headphone adapter, a prosumer audio interface, an ESS Sabre DAC, etc. and they're all full-speed. Seems incredibly common for audio, and it would be difficult to even shop for "real" high-speed USB 2.0 devices. My design goals for my project include the ability to use any number of USB audio devices of any type, though I'd settle for 5 or 6 of them. And really, it seems silly that the Pi 4 can't handle half a dozen full-speed devices, when the Pi 3 reportedly handles them much better.
Oh, I wasn't talking about the official board, I meant the dozens of third-party boards. Any CM4 carrier that supports USB3 has its own PCIe USB chip, external to the CM4. It just happens that a lot of them chose to use the VL805, too, for symmetry with the Pi 4. My questions were: is this bug limited to the VL805, and can it be fixed or is it permanent? For example, on my laptop PC, I can replicate this "not enough bandwidth" failure by connecting 4 full-speed audio devices to a single-TT USB 2.0 hub. However, if I connect those devices to a multi-TT hub, then plug that hub into the single-TT hub attached to the PC, the problem goes away. In theory, that setup is the same as the situation on the Pi, where I'm connecting my multi-TT hub fulla full-speed audio devices to the Pi's onboard single-TT hub, which is connected to the Pi's USB controller. Why does that fail on the Pi but not on my PC? |
Describe the bug
Multiple USB sound cards (even two) can't play simultaneously in Raspberry Pi 4B. Works fine in RPI3.
When trying to play sound second attempt fails with "Not enough bandwidth".
Bandwidth is not that high. Seems it is not properly calculated/checked by USB driver.
Also Pi3 works with even higher bandwidth.
To reproduce
Playing 10secs one by one - OK
Playing 10secs simultaneously - FAIL
Expected behaviour
Both soundcards work. Just like it work on Raspberry 3, look:
Actual behaviour
But on 4B attempt to open second sound card fails with error from usb subsystem: "Not enough bandwidth for new device state.". ALSA returns error to the application. First card works. When first card stops playing I can finally play sound on the second card.
System
cat /etc/rpi-issue)?vcgencmd version)?uname -a)?(it's recompiled from master, I've also tried 5.10.y branch - the same result)
Logs
Additional context
Being inspired by new powerful USB3.0 controller advertisement I've ordered Pi4 specially to connect many (like 5-6) USB sound cards. It's pity that I can't connect even 2. And Pi 3 (not even 3+) works better!
Both soundcards are USB AudioQuest DragonFly Black v1.5.
It has only one stereo out, no mic, nothing else.
Tried on lowest possible frequency - 44100. While Pi 3 works fine with 96000.
Only Ethernet cable, Power, and these 2 USB cards are connected to the device.
Does not matter which ports, blue or 2.0 give the same result. Using 3.0 or 2.0 hub does not change anything.
I heard Type-C port can be used with power via gpio, but it does not work for me this way.
usbtop reports about 374.11 kb/s which is much less than even USB 2.0 can handle.
Here are USB details:
The text was updated successfully, but these errors were encountered: