93db51d06b
The current driver code assumes blindly that all found sample rates for the same endpoint from the UAC2 and UAC3 descriptors can be used no matter which altsetting, but actually this was wrong: some devices accept only limited sample rates in each altsetting. For determining which altsetting supports which rate, we need to verify each sample rate and check the validity via UAC2_AS_VAL_ALT_SETTINGS. This control reports back the available altsettings as a bitmap. This patch implements the missing piece above, the verification and reconstructs the sample rate tables based on the result. An open question is how to deal with the altsettings that ended up with no valid sample rates after verification. At least, there is a device that showed this problem although the sample rates did work in the later usage (see bug link). For now, we accept such an altset as is, assuming that it's a firmware bug. Reported-by: Dylan Robinson <dylan_robinson@motu.com> Tested-by: Keith Milner <kamilner@superlative.org> Tested-by: Dylan Robinson <dylan_robinson@motu.com> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203 Link: https://lore.kernel.org/r/20201123085347.19667-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
16 lines
514 B
C
16 lines
514 B
C
/* SPDX-License-Identifier: GPL-2.0 */
|
|
#ifndef __USBAUDIO_CLOCK_H
|
|
#define __USBAUDIO_CLOCK_H
|
|
|
|
int snd_usb_init_sample_rate(struct snd_usb_audio *chip, int iface,
|
|
struct usb_host_interface *alts,
|
|
struct audioformat *fmt, int rate);
|
|
|
|
int snd_usb_clock_find_source(struct snd_usb_audio *chip,
|
|
struct audioformat *fmt, bool validate);
|
|
|
|
int snd_usb_set_sample_rate_v2v3(struct snd_usb_audio *chip,
|
|
const struct audioformat *fmt,
|
|
int clock, int rate);
|
|
|
|
#endif /* __USBAUDIO_CLOCK_H */
|