Re: [REGRESSION] ALSA: usb-audio: Behringer USB-MIDI output stalls, since "Use strings in struct usb_dev for manufacturer & co"

[Takashi Iwai <tiwai@suse.de>]

On Tue, 29 Sep 2026 12:55:11 +0200,
Jan Lentfer wrote:
> 
> Hi,
> 
> since 7.1, USB-MIDI output to several Behringer synths stalls completely
> after the synth is switched on or re-plugged. I traced it to the missing
> string-descriptor reads after SET_CONFIGURATION, which were removed by
> 
>   "ALSA: usb-audio: Use strings in struct usb_dev for manufacturer & co"
>   (Takashi Iwai, posted 2026-03-05)
> 
> The firmware of these devices evidently only starts accepting bulk-OUT
> data after one more control request following SET_CONFIGURATION.
> Until 7.0, snd-usb-audio happened to send two: the usb_string() calls
> in usb_audio_make_shortname() / usb_audio_make_longname().
> 
> #regzbot introduced: v7.0..v7.1
> 
> Affected (class-compliant USB-MIDI 1.0, full speed, bulk EP 0x02 OUT /
> EP 0x81 IN, one altsetting):
>   1397:1230  BEHRINGER K-2 MK II      (verified: usbmon + workaround)
>   1397:1249  BEHRINGER KOBOL EXPANDER (same symptom; 7.0 good, 7.1 bad)
>   1397:1256  BEHRINGER 2-XM           (same symptom on 7.2)
> Not affected: Behringer PRO-800, Roland SE-02 (0582:0201).
> 
> Kernels: Liquorix builds of the stable releases, Debian 12 amd64.
> 7.0.14 is good; 7.1.12 and 7.2.4 - 7.2.8 are bad.
> I have not run a vanilla build, but the usbmon diff below points
> directly at the mainline change. Liquorix report:
> https://github.com/damentz/liquorix-package/issues/233
> 
> Symptom
> -------
> After the synth is power-cycled while connected, the first 7 MIDI
> messages leave the rawmidi buffer, and none of them reaches the synth.
> After that the output is stuck:
> 
>   /proc/asound/cardN/midi0:  Tx bytes: 21   Avail: 4021 (of 4096)
>   dmesg on close:  rawmidi drain error (avail = 4081, buffer_size = 4096)
> 
> usbmon shows 7 bulk-OUT URBs (= OUTPUT_URBS) submitted with correct
> USB-MIDI packets and never completed (the device NAKs forever). No
> error is logged. Once stalled, only a new control request (see below)
> or booting a 7.0 kernel recovers it. A synth that was already working
> keeps working across a reboot into 7.1+, because nothing re-enumerates
> its firmware state; only a fresh power-on triggers the problem.
> 
> Ruled out: IRQ threading (same with nothreadirqs), RT IRQ priorities,
> the shared IRQ line, hubs vs. root port, userspace (aplaymidi alone),
> runtime PM, MIDI channel.
> 
> usbmon: power cycle of the K-2 MK II, 7.0.14 vs 7.2.8
> -----------------------------------------------------
> Byte-identical up to and including SET_CONFIGURATION. Then:
> 
> 7.0.14:
>   S Co:3:021:0 s 00 09 0001 0000 0000 0         SET_CONFIGURATION 1
>   C Co:3:021:0 0 0
>   S Ci:3:021:0 s 80 06 0302 0409 00ff 255 <     string 2 (product)
>   C Ci:3:021:0 0 20 = 14034b00 2d003200 ...      "K-2 MK II"
>   S Ci:3:021:0 s 80 06 0301 0409 00ff 255 <     string 1 (manufacturer)
>   C Ci:3:021:0 0 20 = 14034200 65006800 ...      "Behringer"
>   S Bi:3:021:1 -115 64 <   (x7)
>   S Bo:3:021:2 -115 4 = 09933c6e
>   C Bo:3:021:2 0 4 >                             completes in ~0.2 ms
>   ... all further Bo complete
> 
> 7.2.8:
>   S Co:2:022:0 s 00 09 0001 0000 0000 0         SET_CONFIGURATION 1
>   C Co:2:022:0 0 0
>   (no further control request to the device)
>   S Bi:2:022:1 -115 64 <   (x7)
>   S Bo:2:022:2 -115 4 = 09933c6e
>   ... 6 Bo submitted, none ever completes (capture ran > 60 s)
> 
> Proof / workaround
> ------------------
> On 7.2.8, with the K-2 stalled (7 OUT URBs pending), I issued a single
> GET_DESCRIPTOR(STRING, index 2, 0x0409) from userspace via usbfs
> USBDEVFS_CONTROL. The pending URBs completed immediately (Tx 21 -> 96,
> buffer drained), and all later MIDI output works.
> As a stop-gap I now do that from a udev rule when the card appears:
> 
>   ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", \
>     ATTRS{idVendor}=="1397", \
>     RUN+="/usr/local/sbin/behringer-usbmidi-wake $attr{busnum}
> $attr{devnum}"
> 
> With it, a power-cycled K-2 MK II works on 7.2.8 without manual steps.
> 
> Possible fix
> ------------
> A quirk for these IDs (or all of 1397:*) that issues one standard
> control request after SET_CONFIGURATION, e.g. reading a string
> descriptor, before the MIDI endpoints are used. Alternatively, restore
> an actual usb_string() read in the card-name path. I'm happy to test
> patches, and I can send the full usbmon captures and descriptor dumps.
> 
> USB descriptors (K-2 MK II; Kobol Expander identical apart from strings):
> - bcdUSB 2.00, full speed, bcdDevice 2.00, 1 configuration, self powered
> - Interface 0: AudioControl, no endpoints
> - Interface 1: MIDIStreaming, 1 altsetting, 2 endpoints
>   - EP 0x02 OUT bulk, 64 bytes, 1 embedded jack
>   - EP 0x81 IN bulk, 64 bytes, 1 embedded jack
> - Host: Intel 82801JI (ICH10) EHCI, devices behind USB 2.0 hubs
>   (also seen on a UHCI root port)
> 
> Thanks,
> Jan Lentfer
> 
> Disclaimer: analyzed and reported with AI support

Thanks for the report.

Can this be fixed by applying the same boot quirk for Behringer CM1A
(something like below)?

Or do we need explicit usb_string() calls instead?  If yes, which one
(iProduct, iManufacturer) matters?


thanks,

Takashi

-- 8< --
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1785,6 +1785,9 @@ int snd_usb_apply_boot_quirk_once(struct usb_device *dev,
 	case USB_ID(0x07fd, 0x0008): /* MOTU M Series, 1st hardware version */
 		return snd_usb_motu_m_series_boot_quirk(dev);
 	case USB_ID(0x1397, 0x1234): /* Behringer CM1A */
+	case USB_ID(0x1397, 0x1230): /* Behringer K-2 Mk II */
+	case USB_ID(0x1397, 0x1249): /* Behringer Kobol Expander */
+	case USB_ID(0x1397, 0x1256): /* Behringer 2-XM */
 		return snd_usb_cm1a_boot_quirk(dev);
 	case USB_ID(0x2717, 0xd005): /* Xiaomi audio connector */
 		snd_usb_xiaomi_boot_quirk(dev);