Takashi Iwai wrote: > On Fri, 22 Jan 2021 11:03:48 +0100, > Jamie Heilman wrote: > > > > Takashi Iwai wrote: > > > You seem hitting a firmware bug, and it doesn't look like the only > > > case. Interestingly, the backport of 5.11 USB-audio stuff on 5.3 > > > kernel on openSUSE Leap 15.2 caused a similar bug on Steinberg device, > > > while it worked with 5.11-rc. So I thought this specific with the > > > older kernel (in USB core changes or such), but my guess seems wrong, > > > and the bug looks remaining in 5.11 for some cases. > > > > > > Below is the fix patch. Please give it a try. > > > > > > > > > thanks, > > > > > > Takashi > > > > > > -- 8< -- > > > From: Takashi Iwai > > > Subject: [PATCH] ALSA: usb-audio: workaround for iface reset issue > > > > > > The recently introduced sample rate validation code seems causing a > > > problem on some devices; namely, after performing this, the bus gets > > > screwed and it influences even on other USB devices. > > > As a quick workaround, perform it only for the necessary devices; > > > currently MOTU devices are known to need the valid altset checks, so > > > filter out other devices. > > > > > > Fixes: 93db51d06b32 ("ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3") > > > Reported-by: Jamie Heilman > > > BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203 > > > Signed-off-by: Takashi Iwai > > > --- > > > sound/usb/format.c | 11 +++++++++++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git a/sound/usb/format.c b/sound/usb/format.c > > > index 9ebc5d202c87..e6ff317a6785 100644 > > > --- a/sound/usb/format.c > > > +++ b/sound/usb/format.c > > > @@ -466,6 +466,17 @@ static int validate_sample_rate_table_v2v3(struct snd_usb_audio *chip, > > > unsigned int nr_rates; > > > int i, err; > > > > > > + /* performing the rate verification may lead to unexpected USB bus > > > + * behavior afterwards by some unknown reason. Do this only for the > > > + * known devices. > > > + */ > > > + switch (USB_ID_VENDOR(chip->usb_id)) { > > > + case 0x07fd: /* MOTU */ > > > + break; > > > + default: > > > + return 0; /* don't perform the validation as default */ > > > + } > > > + > > > table = kcalloc(fp->nr_rates, sizeof(*table), GFP_KERNEL); > > > if (!table) > > > return -ENOMEM; > > > > Well, with this patch, while I can get it to seemingly initialize > > without errors by replugging, I can't actually get it to work. Jack > > says: > > > > Starting jack server... > > JACK server starting in realtime mode with priority 10 > > self-connect-mode is "Don't restrict self connect requests" > > Acquired audio card Audio1 > > creating alsa driver ... hw:CARD=hiFace2,DEV=0|-|1024|3|96000|0|0|nomon|swmeter|-|32bit > > ERROR: ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to capture-only mode > > Released audio card Audio1 > > ERROR: Cannot initialize driver > > ERROR: JackServer::Open failed with -1 > > ERROR: Failed to open server > > Which kernel did you test? There have been a few more USB-audio fixes > that landed to Linus tree yesterday, so you'd need to test with it (in > addition to the previous patch). Sorry, thought that'd be clear from the alsa-info output, but yes, the tip of Linus's tree at the time: 5.11.0-rc4-00164-g83d09ad4b950 > > here's what aplay does when it tries: > > > > aplay: main:830: audio open error: Invalid argument > > > > strace of that says: > > openat(AT_FDCWD, "/dev/snd/pcmC1D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EINVAL (Invalid argument) > > Hm, it's weird that open returns -EINVAL, not the later ioctl... > > > I dug up a different USB sound device (bithead) and plugged it in, it > > still works just fine with the same commands. > > > > The only difference I see in the alsa-info output is that > > > > control.7 { > > iface CARD > > name 'Keep Interface' > > value false > > comment { > > access 'read write' > > type BOOLEAN > > count 1 > > } > > } > > > > has gone missing. > > This is an intended change and should be irrelevant. Groovy. > If the problem is still seen with the very latest Linus tree and the > previous patch, please enable the dyndbg, e.g. pass dydbg=+p option to > snd-usb-audio module, i.e. reload like > modprobe snd-usb-audio dydbg=+p > or boot with > snd_usb_audio.dyndbg=+p > boot option, retest, and give the kernel messages. OK, updated to 5.11.0-rc4-00202-gfe75a21824e7, repatched & rebuilt with: CONFIG_SND_DEBUG=y CONFIG_SND_CTL_VALIDATION=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DYNAMIC_DEBUG_CORE=y and added dyndbg=+p to my snd-usb-audio options, dmesg after an attempted aplay execution is attached. For grins I built a 5.10.9 kernel with the same config to compare ... the difference between 5.10.9 and 5.11.0-rc4-00202-gfe75a21824e7 debug output is basically: +usb 1-1.1.2: 1:1: found sync_ep=0x81, iface=1, alt=1, implicit_fb=0 usb 1-1.1.2: 1:1: add audio endpoint 0x1 +usb 1-1.1.2: Creating new data endpoint #1 +usb 1-1.1.2: Creating new sync endpoint #81 +usb 1-1.1.2: 1:1 Set sample rate 192000, clock 40 usb 1-1.1.2: [10] FU [M2Tech Audio 2.0 Output Playback Switch] ch = 2, val = 0/1/1 usb 1-1.1.2: [10] FU [M2Tech Audio 2.0 Output Playback Switch] ch = 1, val = 0/1/1 usb 1-1.1.2: RANGE setting not yet supported usb 1-1.1.2: [10] FU [M2Tech Audio 2.0 Output Playback Volume] ch = 2, val = -32512/0/256 usb 1-1.1.2: RANGE setting not yet supported usb 1-1.1.2: [10] FU [M2Tech Audio 2.0 Output Playback Volume] ch = 1, val = -32512/0/256 ...and then on 5.10.9 once I start up jackd ... -usb 1-1.1.2: setting usb interface 1:1 -usb 1-1.1.2: Creating new playback data endpoint #1 -usb 1-1.1.2: Creating new capture sync endpoint #81 -usb 1-1.1.2: Setting params for ep #1 (type 0, 12 urbs), ret=0 -usb 1-1.1.2: Setting params for ep #81 (type 1, 4 urbs), ret=0 -usb 1-1.1.2: Starting data EP @00000000d63f36f3 -usb 1-1.1.2: Starting sync EP @00000000e9f3024b -- Jamie Heilman http://audible.transient.net/~jamie/