Bug 213425 - EDIROL UA-101 (in USB 1.1 mode, not USB2) hardware bug (freezes) when connected to USB
Summary: EDIROL UA-101 (in USB 1.1 mode, not USB2) hardware bug (freezes) when connect...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-13 05:07 UTC by Lucas Endres
Modified: 2021-06-27 01:00 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.12.0-rc8-next-20210422
Tree: Mainline
Regression: No


Attachments

Description Lucas Endres 2021-06-13 05:07:44 UTC
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
Comment 1 Takashi Iwai 2021-06-18 15:11:29 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?
Comment 2 Lucas Endres 2021-06-27 01:00:05 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.