[alsa-devel] [PATCH] ALSA: usb-audio - Capture and duplex support for Digidesign Mbox 1 sound card.

Damien Zammit damien.zammit at gmail.com
Sat Mar 29 13:27:12 CET 2014

On 29/03/14 16:01, Mark Hills wrote:
> I'm a bit late to this, but I think a more generic quirk is necessary.
Thanks Mark, I don't know much about other devices, but I have provided
some comments about my latest code:

> Or does some kind of spec define that these should be applied to the first 
> endpoint and that all will be affected?
I used educated guesses to make the Mbox 1 functional:

I set the altsetting of the interface based on the value provided in the
first endpoint entry of the quirk, (since they must be all the same for
a shared interface):
+		alts = &iface->altsetting[fp[0]->altset_idx];

This works for any device where the interface is shared across multiple
endpoints, right?  Otherwise you wouldn't use this new quirk type.

After reading all the quirk data and adding streams one by one, I went
on to configure the interface based on the quirk data for the first entry:
+	usb_set_interface(chip->dev, fp[0]->iface, 0);
+	snd_usb_init_pitch(chip, fp[0]->iface, alts, fp[0]);
+	snd_usb_init_sample_rate(chip, fp[0]->iface, alts, fp[0],

I assumed that the supported rates for all interfaces was the same and
that they could be read from the first endpoint entry in the quirk.
I know, most of the quirk data is ignored, but they share the same
interface so most of it is redundant anyway, isn't it?

I can't see what limitations this multi-endpoint quirk type has that
might need to be adjusted for other devices.  Can you provide an example
of a device that uses multiple endpoints within a single interface whose
supported rates differ between endpoints?  If you can, then I also think
we need a better model.  If you can't, is it because it is impossible?


More information about the Alsa-devel mailing list