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