linux-kernel - RE: [alsa-devel] ALSA:usb audio Higher sample rates on usb audio no longer working.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <C672AA6DAAC36042A98BAD0B0B25BDA94CB021CE@BGSMSX104.gar.corp.intel.com>
Date:   Fri, 4 Jan 2019 16:52:03 +0000
From:   "Gopal, Saranya" <saranya.gopal@...el.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Takashi Iwai <tiwai@...e.de>, Con Kolivas <kernel@...ivas.org>
CC:     "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "felipe.balbi@...ux.intel.com" <felipe.balbi@...ux.intel.com>
Subject: RE: [alsa-devel] ALSA:usb audio Higher sample rates on usb audio no
 longer working.

> > [ 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