[alsa-devel] A problem with USB audio devices and the UHCI scheduler
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
Monty Montgomery wrote:
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?
You cannot fix it in the audio driver; bandwidth allocation is done in the controller driver, and that one doesn't know that your device lies about its bandwidth requirements.
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.
The device is supposed to use alternate settings for this.
Can't you change its firmware?
Regards, Clemens
You cannot fix it in the audio driver; bandwidth allocation is done in the controller driver,
Yes, I came to this practical conclusion too.
and that one doesn't know that your device lies about its bandwidth requirements.
Oh, it's not lying. The wmaxPacketsize is accurate. It's just for a range of sample rates, so it's overkill for the lower ones.
The device is supposed to use alternate settings for this.
The device does use altsets for different sample formats and input/output channels, just not altsets for each sample rate (as supported/encouraged by the Audio Class... or has the Audio Class since been amended to do away with sample rate ranges?)
In any case, it obeys the Audio Class spec and uses it appropriately to my naive reading.
Can't you change its firmware?
Oof, that's one hairy yak. Is it really the case that other Audio Class devices never make use of the "multiple sample rates in an altset" feature?
Not answering the question, but related:
I couldn't even get linux-firmware to ship *working* firmware when I last tried a few years ago. We're still shipping the nonfunctional firmware that got corrupted in the pre-2.6.21 cleanup. I submitted updated firmware and folks wouldn't take it because emagic/Apple didn't license it clearly (the update CD had no license text in any form whatsoever), and then people didn't want to restore Tapio's original working firmware either because he couldn't be contacted to confirm a license for it... Granted, I gave up / got distracted pretty quickly, so the blame is mostly mine.
But that's semi-irrelevant to the technical question at hand really. OHCI has no problem managing this device's bandwidth appropriately, and neither Win nor Mac OS seem to overprovision on UHCI. If this really is just another case of "I have to package and ship custom drivers for devices like this", I suppose I'll have to live with that.
In any case, yes I see this is a conceptually weird problem. I'm just looking for a practical solution that avoids me maintaining a private fork. Here's hoping for one :-)
Cheers,
Monty
Monty Montgomery wrote:
The device does use altsets for different sample formats and input/output channels, just not altsets for each sample rate (as supported/encouraged by the Audio Class...
Supported, but not encouraged: | A typical use of alternate settings is to provide a way to change | the bandwidth requirements an active AudioStreaming interface | imposes on the USB.
Is it really the case that other Audio Class devices never make use of the "multiple sample rates in an altset" feature?
They do, but not when bandwidth matters.
Regards, Clemens
participants (2)
-
Clemens Ladisch -
Monty Montgomery