Bug 213425
Summary: | EDIROL UA-101 (in USB 1.1 mode, not USB2) hardware bug (freezes) when connected to USB | ||
---|---|---|---|
Product: | Drivers | Reporter: | Lucas Endres (jaffa225man) |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | NEW --- | ||
Severity: | normal | CC: | jaffa225man, tiwai |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 5.12.0-rc8-next-20210422 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Lucas Endres
2021-06-13 05:07:44 UTC
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. |