A question for Clemens et al...
Background: I can run a USB audio device at 6ch/24 bit single duplex, but I cannot run the same device at 16 bit stereo full duplex. UHCI and EHCI both say 'not enough bandwidth' (OHCI works).
EHCI's scheduling issues are well known, but I was surprised UHCI could not schedule this either. The cause is simple; UHCI (and EHCI) use the endpoint's wMaxPacketSize for all bandwidth allocation. My device supports all of its sample rates on the same altset, with a wMaxPacketSize matching the highest (96kHz) rate. So, the HCD is reserving most of the USB bus's bandwidth regardless of the actual requirements.
How should I approach fixing this in the driver? There's currently no means to communicate a desired bandwidth reservation to the HCD from USB audio, so I'd have to extend even the quirks. I was considering shadowing the endpoint's original wMaxPacketSize in the substream struct, and replacing the value in the endpoint's native descriptor while the stream is running. I have no idea how much trouble that would cause (eg, corruption elsewhere, or middle finger from Linus).
Suggestions? For now I have things working by disabling UHCI's initial bandwidth checks (as there is in fact more than enough bandwidth to schedule what I'm doing) but I'd like a more permanent solution.
Monty