> > [ Adding linux-usb ML to Cc, as it's a core USB issue ] > > > > So the device seems incorrectly advertising as if it were supporting > > UAC3 -- assuming the device is still not UAC3-capable. > > > > IOW, it's a buggy firmware. We need some blacklisting, or revert the > > commit for now, unless any real UAC3 device comes up to the market. > > IIRC an UAC3-capable device is required to expose a backwards-compatible > configuration (either UAC1 or UAC2). Maybe an additional test can be > done to harden the detection so that UAC3 is only chosen if indeed a > second audio configuration is present as well. > > I also vaguely recall there was talk about adding information in the BOS > descriptor, but I don't know if this was ever published. > > -Pierre The current detection logic is that UAC3 configuration is chosen only when a device has a configuration with audio interface supporting UAC3 protocol. Additionally, it already makes sure that UAC3 is selected only when there is more than one configuration. Otherwise, the first configuration is chosen by default. So, the patch does not affect existing UAC1 and UAC2 devices. As Iwai said, this issue seems to be because of a buggy firmware which wrongly advertises UAC3-capability. Could we add some quirk to select another configuration for this particular device? I see that there is a similar in quirk in sound/usb/quirks.c (snd_usb_fasttrackpro_boot_quirk) . Could something like that be done for this particular device? And since I was not part of the initial mail thread, I might have missed some information. Could someone give me lsusb -v output for this USB audio device. Thanks, Saranya
