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

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

[Jan Lentfer]

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

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

[Takashi Iwai]

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);

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

[Jan Lentfer]

> 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);


The CM1A quirk should be sufficient. No usb_string() is needed.

I reproduced the CM1A quirk's request from userspace on 7.2.8 (usbfs
USBDEVFS_CONTROL, no wake-up udev rule active):

1. Power-cycle the K-2 MK II and send notes: the output stalls as before
    (rawmidi Tx 21, avail 4021, 7 bulk-OUT URBs pending).
2. Send a single GET_DESCRIPTOR(DEVICE, 18 bytes)
    (80 06 0100 0000 0012), nothing else. The pending URBs complete
    immediately (Tx 21 -> 96, buffer drained), and all following MIDI
    output works.

A GET_DESCRIPTOR(STRING 2) instead has the same effect (tested
earlier). So it looks like any standard control request after
SET_CONFIGURATION wakes the endpoint, same as on the CM1A.

I have only verified this on the K-2 MK II (1397:1230). The KOBOL
EXPANDER (1397:1249) and 2-XM (1397:1256) run the same firmware
family, have identical descriptors and show the identical stall, so
I'd expect the quirk to cover them as well.

Thanks,
Jan

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

[Takashi Iwai]

On Tue, 29 Sep 2026 13:42:04 +0200,
Jan Lentfer wrote:
> 
> > 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);
> 
> 
> The CM1A quirk should be sufficient. No usb_string() is needed.
> 
> I reproduced the CM1A quirk's request from userspace on 7.2.8 (usbfs
> USBDEVFS_CONTROL, no wake-up udev rule active):
> 
> 1. Power-cycle the K-2 MK II and send notes: the output stalls as before
>    (rawmidi Tx 21, avail 4021, 7 bulk-OUT URBs pending).
> 2. Send a single GET_DESCRIPTOR(DEVICE, 18 bytes)
>    (80 06 0100 0000 0012), nothing else. The pending URBs complete
>    immediately (Tx 21 -> 96, buffer drained), and all following MIDI
>    output works.
> 
> A GET_DESCRIPTOR(STRING 2) instead has the same effect (tested
> earlier). So it looks like any standard control request after
> SET_CONFIGURATION wakes the endpoint, same as on the CM1A.
> 
> I have only verified this on the K-2 MK II (1397:1230). The KOBOL
> EXPANDER (1397:1249) and 2-XM (1397:1256) run the same firmware
> family, have identical descriptors and show the identical stall, so
> I'd expect the quirk to cover them as well.

Thanks for quick tests!

I'll prepare the fix patch for upstream in a similar form as given in
the previous mail.


Takashi