I finally finished with git bisect, only to find that the commit causing it was the one that caused the EDIROL UA-101's MIDI device to reappear which I helped verify working. The full version of the patch, now part of the linux-next branch causes the UA-101 to freeze when set to USB 1.1 (full speed) mode, and I'm not entirely sure why I didn't see the behavior with the prior version of the patch. Here's a good method to verify the UA-101 is freezing: First, on the back of the UA-101, switch "Hi SPEED" mode off. Then, as usual, turning the UA-101 on and connecting an active audio signal to its inputs, before connecting USB causes the LEVELS LEDs to light up accordingly. When USB is, then, connected to a post-commit kernel, the LEDs freeze, even when the inputs are unplugged, until (with USB again disconnected) the UA-101 is power cycled. The computer, likewise, won't communicate with it beyond some initial activation, with errors like this while trying to capture: arecord -D plughw:UA101 -f S24_3LE -r 48000 -c 2 ./file.wav arecord: main:830: audio open error: Connection timed out (dmesg:) [ 188.956481] usb 4-1.5: cannot initialize interface; error -110: unknown error [ 194.076450] usb 4-1.5: cannot initialize interface; error -110: unknown error [ 199.196407] usb 4-1.5: cannot initialize interface; error -110: unknown error I was told by Alan Stern, of the USB developers (https://bugzilla.kernel.org/show_bug.cgi?id=212955#c22), that reordering the USB communication might help, since it worked when snd-usb-audio was used, but not with that blacklisted in favor of snd-ua101 only. As I have a mediocre understanding of the USB code for ALSA drivers, I was hoping someone could point me to which file(s) contain the USB commands that would have been used for the UA-101 prior to blacklisting it from the snd-usb-audio module, so I can compare its lines to those found in the snd-ua101's module. The final git bisect returned this: d763145312582c08c4e9ed99d61276cde8488256 is the first bad commit commit d763145312582c08c4e9ed99d61276cde8488256 Author: Takashi Iwai <tiwai@suse.de> Date: Thu Apr 8 09:56:56 2021 +0200 ALSA: usb-audio: Skip probe of UA-101 devices UA-101 device and co are supported by another driver, snd-ua101, but the USB audio class driver (snd-usb-audio) catches all and this resulted in the lack of functionality like missing MIDI devices. This patch introduces a sort of deny-listing for those devices to just return -ENODEV at probe in snd-usb-audio driver, so that it falls back to the probe by snd-ua101. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212477 Link: https://lore.kernel.org/r/20210408075656.30184-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> sound/usb/card.c | 2 ++ sound/usb/quirks-table.h | 21 +++++++++++++++++++++ sound/usb/usbaudio.h | 1 + 3 files changed, 24 insertions(+) I'm really sorry to spring this on you, especially after having played such a major role in getting that commit applied in the first place. Due to my involvement, I see it as my duty to try my hardest to correct it. Thanks for your understanding and support, Lucas Endres
Well, this implies that snd-ua101 has been already broken with that hub. The commit above merely enforces the binding with snd-ua101 driver, with the assumption that the device gets managed better by that driver. So, after reverting the commit, and blacklisting snd-ua101, does the audio part work well with snd-usb-audio again? The MIDI can be forgotten for now, just about the audio. And if it works, does it on all ports / hubs?
I'm sorry for taking so long to get back to you on this. I noticed it a bit late, blacklisted snd_ua101, but then had to wait for the pre-commit kernel to build, and then find the time for testing again. But to finally answer you, yes! With "Hi-SPEED" mode both disabled (USB 1.1) and enabled (USB2) on both USB2 and USB3 ports (all the hubs in my system) it records and plays back, even in full-duplex (with arecord begun before using aplay). And you're correct, the MIDI port is, again, no longer available with snd_ua101 blacklisted. The card name still changes between the two modes. In USB 1.1 mode it's "hw:USB1", but in USB 2 mode it's "hw:UA101". Also, the format changes (probably a true hardware limitation, due to speed). In USB 1.1 it's "S24_3LE", and for USB 2 it's "S32_LE" (and it also provides all the channels as expected, rather than just stereo). If you need any more information, I'll be happy to provide it. Thanks again, Takashi! I was trying to fruitlessly rearrange lines of code in sound/usb/misc/ua101.c before you responded.