A problem with USB audio devices and the UHCI scheduler

A problem with USB audio devices and the UHCI scheduler

[Monty Montgomery]

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

Re: A problem with USB audio devices and the UHCI scheduler

[Clemens Ladisch]

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

Re: A problem with USB audio devices and the UHCI scheduler

[Monty Montgomery]

> 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

Re: A problem with USB audio devices and the UHCI scheduler

[Clemens Ladisch]

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