You are not logged in.
Dear all
I’m experiencing a strange issue with my USB MIDI devices that only started about a month ago (after years of working fine).
I am currently running "Linux 6.16.7-arch1-1" (full system information can be accessed here: https://nextcloud.paulussen.id/index.ph … GqwRJFPLj4).
I have two USB MIDI devices:
* Abstrakt Instruments Avalon Bassline (synthesizer)
* Akai MPK261 (keyboard)
They are usually connected via powered hubs – I’ve tested direct connections (USB 3 and 2) and other cables as well.
After some time (usually during active use in Bitwig Studio), one of the devices stops responding and disappears from ALSA. At that moment the kernel log starts spamming:
usb 3-1.2: config 13 interface 2 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
usb 3-1.2: usb_submit_urb failed: -32After this, the device no longer works until I power-cycle it.
This happens to both devices, so it’s unlikely to be a device-specific hardware fault.
Has anyone seen similar issues recently with USB MIDI devices and newer kernels?
Here is what demseg says when I connect the devices:
Abstrakt Instruments Avalon Bassline:
[ 489.991433] usb 3-2.4.4.3: new full-speed USB device number 16 using xhci_hcd
[ 490.098309] usb 3-2.4.4.3: New USB device found, idVendor=16c0, idProduct=0444, bcdDevice= 1.00
[ 490.098314] usb 3-2.4.4.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 490.098317] usb 3-2.4.4.3: Product: Avalon MIDI
[ 490.103311] usb 3-2.4.4.3: Quirk or no altset; falling back to MIDI 1.0Akai MPK261:
[ 678.359284] usb 3-1.4.4.2: new full-speed USB device number 21 using xhci_hcd
[ 678.456494] usb 3-1.4.4.2: config 13 interface 2 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[ 678.467494] usb 3-1.4.4.2: New USB device found, idVendor=09e8, idProduct=0025, bcdDevice= 1.00
[ 678.467498] usb 3-1.4.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 678.467501] usb 3-1.4.4.2: Product: MPK261
[ 678.467503] usb 3-1.4.4.2: Manufacturer: Akai
[ 678.467505] usb 3-1.4.4.2: SerialNumber: NO SERIAL NUMBER
[ 678.525503] usb 3-1.4.4.2: Quirk or no altset; falling back to MIDI 1.0
[ 678.560660] input: Akai MPK261 as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:3b:00.1/usb3/3-1/3-1.4/3-1.4.4/3-1.4.4.2/3-1.4.4.2:13.2/0003:09E8:0025.000C/input/input35
[ 678.651390] hid-generic 0003:09E8:0025.000C: input,hidraw9: USB HID v0.10 Keyboard [Akai MPK261] on usb-0000:3b:00.1-1.4.4.2/input2And this is what the log looks like when things go sideways:
[ 828.218403] usb 3-1.4.4.2: urb status -32
[ 828.218628] usb 3-1.4.4.2: urb status -32
[ 828.221878] usb 3-1.4.4.2: urb status -32
...
[ 829.591533] usb 3-1.4.4.2: reset full-speed USB device number 21 using xhci_hcd
[ 829.592367] retire_capture_urb: 12 callbacks suppressed
[ 829.730550] usb 3-1.4.4.2: Quirk or no altset; falling back to MIDI 1.0[ 916.989375] usb 3-1.4.4.2: USB disconnect, device number 21
[ 918.236383] usb 3-1.4.4.2: new full-speed USB device number 23 using xhci_hcd
[ 918.333169] usb 3-1.4.4.2: config 13 interface 2 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[ 918.344169] usb 3-1.4.4.2: New USB device found, idVendor=09e8, idProduct=0025, bcdDevice= 1.00
[ 918.344173] usb 3-1.4.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 918.344175] usb 3-1.4.4.2: Product: MPK261
[ 918.344178] usb 3-1.4.4.2: Manufacturer: Akai
[ 918.344180] usb 3-1.4.4.2: SerialNumber: NO SERIAL NUMBER
[ 918.399179] usb 3-1.4.4.2: Quirk or no altset; falling back to MIDI 1.0
[ 918.431337] input: Akai MPK261 as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:3b:00.1/usb3/3-1/3-1.4/3-1.4.4/3-1.4.4.2/3-1.4.4.2:13.2/0003:09E8:0025.000D/input/input36
[ 918.527458] hid-generic 0003:09E8:0025.000D: input,hidraw9: USB HID v0.10 Keyboard [Akai MPK261] on usb-0000:3b:00.1-1.4.4.2/input2
[ 919.037388] usb 3-1.4.4.2: USB disconnect, device number 23
[ 920.285362] usb 3-1.4.4.2: new full-speed USB device number 24 using xhci_hcd
[ 920.384184] usb 3-1.4.4.2: config 13 interface 2 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[ 920.396180] usb 3-1.4.4.2: New USB device found, idVendor=09e8, idProduct=0025, bcdDevice= 1.00
[ 920.396184] usb 3-1.4.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 920.396186] usb 3-1.4.4.2: Product: MPK261
[ 920.396188] usb 3-1.4.4.2: Manufacturer: Akai
[ 920.396190] usb 3-1.4.4.2: SerialNumber: NO SERIAL NUMBER
[ 920.447198] usb 3-1.4.4.2: Quirk or no altset; falling back to MIDI 1.0
[ 920.481372] input: Akai MPK261 as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:3b:00.1/usb3/3-1/3-1.4/3-1.4.4/3-1.4.4.2/3-1.4.4.2:13.2/0003:09E8:0025.000E/input/input37
[ 920.578484] hid-generic 0003:09E8:0025.000E: input,hidraw9: USB HID v0.10 Keyboard [Akai MPK261] on usb-0000:3b:00.1-1.4.4.2/input2
[ 920.829273] usb 3-1.4.4.2: USB disconnect, device number 24
[ 922.079348] usb 3-1.4.4.2: new full-speed USB device number 25 using xhci_hcd
[ 922.178197] usb 3-1.4.4.2: config 13 interface 2 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[ 922.190196] usb 3-1.4.4.2: New USB device found, idVendor=09e8, idProduct=0025, bcdDevice= 1.00
[ 922.190200] usb 3-1.4.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 922.190202] usb 3-1.4.4.2: Product: MPK261
[ 922.190204] usb 3-1.4.4.2: Manufacturer: Akai
[ 922.190206] usb 3-1.4.4.2: SerialNumber: NO SERIAL NUMBER
[ 922.201023] retire_capture_urb: 4 callbacks suppressed
[ 922.239206] usb 3-1.4.4.2: Quirk or no altset; falling back to MIDI 1.0
[ 922.274454] input: Akai MPK261 as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:3b:00.1/usb3/3-1/3-1.4/3-1.4.4/3-1.4.4.2/3-1.4.4.2:13.2/0003:09E8:0025.000F/input/input38
[ 922.365428] hid-generic 0003:09E8:0025.000F: input,hidraw9: USB HID v0.10 Keyboard [Akai MPK261] on usb-0000:3b:00.1-1.4.4.2/input2
[ 922.621413] usb 3-1.4.4.2: USB disconnect, device number 25
[ 923.860332] usb 3-1.4.4.2: new full-speed USB device number 26 using xhci_hcd
[ 923.959209] usb 3-1.4.4.2: config 13 interface 2 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[ 923.971208] usb 3-1.4.4.2: New USB device found, idVendor=09e8, idProduct=0025, bcdDevice= 1.00
[ 923.971212] usb 3-1.4.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 923.971214] usb 3-1.4.4.2: Product: MPK261
[ 923.971216] usb 3-1.4.4.2: Manufacturer: Akai
[ 923.971218] usb 3-1.4.4.2: SerialNumber: NO SERIAL NUMBER
[ 924.030218] usb 3-1.4.4.2: Quirk or no altset; falling back to MIDI 1.0
[ 924.065403] input: Akai MPK261 as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:3b:00.1/usb3/3-1/3-1.4/3-1.4.4/3-1.4.4.2/3-1.4.4.2:13.2/0003:09E8:0025.0010/input/input39
[ 924.161420] hid-generic 0003:09E8:0025.0010: input,hidraw9: USB HID v0.10 Keyboard [Akai MPK261] on usb-0000:3b:00.1-1.4.4.2/input2
[ 933.448859] usb 3-1.4.4.2: urb status -32
[ 933.449133] usb 3-1.4.4.2: urb status -32
[ 933.452347] usb 3-1.4.4.2: urb status -32
...
[ 934.840276] usb 3-1.4.4.2: reset full-speed USB device number 26 using xhci_hcd
[ 934.980293] usb 3-1.4.4.2: Quirk or no altset; falling back to MIDI 1.0Many thanks for your help in advance!
Update:
I was able to find the cause of my problems.
A couple of weeks, I made changes to the PipeWire/WirePlumber configuration at:
~/.config/wireplumber/wireplumber.conf.d/Specifically, I added a bunch of configuration files containing rules to change the names of my devices. It felt like that worked well. As it turns out, this has actually caused the problems.
Apparently PipeWire/WirePlumber does not like when names are changed on the device level and I should have changed them based on nodes instead.
However, because I was in a hurry, I just removed the files all-together.
And today, I was able to work for hours and hours without the tiniest interruption.
The files I had in place looked like this:
51-fireface-rename.conf:
monitor.alsa.rules = [
{
matches = [
{
device.name = "alsa_card.usb-RME_Fireface_UFX__23609326__A76899246704FC8-00"
}
]
actions = {
update-props = {
device.description = "Fireface UFX, RME"
device.nick = "Fireface UFX, RME"
}
}
}
]52-source-rename.conf:
monitor.alsa.rules = [
{
matches = [
{
device.name = "alsa_card.usb-XMOS_XMOS_USB_Audio_2.0_0000-00"
}
]
actions = {
update-props = {
device.description = "Source, Dangerous Music"
device.nick = "Source, Dangerous Music"
}
}
}
]etc.
In addition to that I also disabled USB autosuspend for affected devices.
For this I created a config file with `sudo nano /etc/udev/rules.d/99-usb-audio.rules` and put in it:
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0424", ATTR{idProduct}=="3fb8", TEST=="power/control", ATTR{power/control}="on"... which includes the result of running lsusb and extracting the `idVendor` and `idProduct` values for the udev rule.
And now everything runs smooth again.
Last edited by amadeuspaulussen (2025-09-26 03:40:48)
Offline
I installed the LTS kernel to see if it would solve the problem. Unfortunately, it did not.
Offline
I seem to have a similar problem that started in the last couple of days; I have a Roland USB midi interface and it's recognized and shows up in lsusb:
[root@archie64 ~]# lsusb|grep -i edirol
Bus 001 Device 004: ID 0582:0052 Roland Corp. EDIROL UM-1SX
[root@archie64 ~]# However no music software lists the midi input or output.
Running kernel 6.16.8-arch1-1.
I do see similar messages about the descriptors:
[ 1.165353] usb 3-2.3: config 1 interface 1 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[ 574.866855] usb 3-2.1: config 1 interface 1 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1In my case the device never seems to work at all, even immediately after booting up.
Last edited by merc68k (2025-09-20 21:32:21)
Offline
I seem to have a similar problem that started in the last couple of days; I have a Roland USB midi interface and it's recognized and shows up in lsusb:
[root@archie64 ~]# lsusb|grep -i edirol Bus 001 Device 004: ID 0582:0052 Roland Corp. EDIROL UM-1SX [root@archie64 ~]#However no music software lists the midi input or output.
Running kernel 6.16.8-arch1-1.
I do see similar messages about the descriptors:
[ 1.165353] usb 3-2.3: config 1 interface 1 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1 [ 574.866855] usb 3-2.1: config 1 interface 1 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1In my case the device never seems to work at all, even immediately after booting up.
Interesting. In my case, however, everything works perfectly at first, and then sometimes after 5 minutes, sometimes after 15, things go sideways.
Offline
Experiencing the same after this weeks updates. I have a dj controller that Mixxx would list it as both a HID and MIDI device, now MIDI is not appearing.
Also getting the 'Quirk or no altset; falling back to MIDI 1.0' warning. Downgrading the kernel and pipewire didn't help. Searched around on the Arch gitlab to see if there was any recent activity related to MIDI and came across this and this, but the portmidi package hasn't been updated since June. Don't see any obvious clues as to what it might be.
Last edited by cats13 (2025-09-21 08:24:28)
Offline
one of the devices stops responding and disappears from ALSA
https://wiki.archlinux.org/title/Power_ … utosuspend - "usbcore.autosuspend=-1" would disable it.
nb. that userspace powermanagement daemons like TLP etc. can and will adjust that value at runtime and you have to configure the behavior there as well.
@merc68k
Do you also get the "urb status -32"? "altsetting 0 has 2 endpoint descriptors" might be just noise
@cats13
after this weeks updates
check your /var/log/pacman.log for what actually was updated, but nb the OP
I’m experiencing a strange issue with my USB MIDI devices that only started about a month ago (after years of working fine).
Does https://archlinux.org/packages/extra/x8 … odeswitch/ do anything about the situation?
@amadeuspaulussen is this actually still a problem since dealing w/ the mediatek chip (which I guess has a BT device on the USB)?
Offline
I booted a Fedora live environment and my MIDI interface worked, but I did still see the messages in the journal: Quirk or no altset; falling back to MIDI 1.0. FWIW.
Offline
Yes, that's noise.
The question is: what errors do you get on the arch system that don't show up on fedora. And notably whether you also get "urb status -32".
Offline
Experiencing the same after this weeks updates. I have a dj controller that Mixxx would list it as both a HID and MIDI device, now MIDI is not appearing.
Having precisely the same issue. The audio interface within the controller is being detected correctly and audio goes through it, but the MIDI side of things just doesn't wanna work. Running "amidi -l" still lists the controller though.
Offline
Yes, that's noise.
The question is: what errors do you get on the arch system that don't show up on fedora. And notably whether you also get "urb status -32".
Unfortunately I don't see other messages when plugging my interface in Arch, including "urb status -32" - I do see some mpt-probe lines logged but that seems to be related to MTP transfers, not MIDI and I saw those in Fedora too.
I tried downgrading all pipewire packages to the earliest I have installed (1:1.4.7-1) and also to kernel 6.16.6, with no improvement.
I may try reverting all packages that have been updated since I installed Arch, which was only about a month ago.
Last edited by merc68k (2025-09-21 22:52:04)
Offline
I just stumbled onto a workaround, in another thread someone mentioned using "aconnect" to list midi devices, so I installed "alsa-utils" and ran:
sudo aconnect -i
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 20: 'UM-1SX' [type=kernel,card=1]
0 'UM-1SX MIDI 1 'And after this, my interface is visible again in my music software. It does seem to be necessary every boot though.
Offline
I just stumbled onto a workaround, in another thread someone mentioned using "aconnect" to list midi devices, so I installed "alsa-utils" and ran:
sudo aconnect -i client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 20: 'UM-1SX' [type=kernel,card=1] 0 'UM-1SX MIDI 1 'And after this, my interface is visible again in my music software. It does seem to be necessary every boot though.
Nice. This worked for me as well. Thank you ![]()
Offline
merc68k wrote:I just stumbled onto a workaround, in another thread someone mentioned using "aconnect" to list midi devices, so I installed "alsa-utils" and ran:
sudo aconnect -i client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 20: 'UM-1SX' [type=kernel,card=1] 0 'UM-1SX MIDI 1 'And after this, my interface is visible again in my music software. It does seem to be necessary every boot though.
Nice. This worked for me as well. Thank you
Same here, this worked for me, the controller is getting picked up by Mixxx now. Thanks a ton for the workaround!
Last edited by Endali (2025-09-22 08:42:03)
Offline
Looks like it's an issue with module loading; running
sudo modprobe snd_seq_midialso fixes it for me.
Offline
Downgrading to systemd (and related) pre-258, e.g. 257.9 makes devices show up since boot again.
Last edited by dimtpap (2025-09-22 17:45:30)
Offline
Offline
Maybe, I'm not using any custom udev rules. How do I confirm?
Offline
Same here, I don't recall making any udev rules for my MIDI to USB interface, everything just worked OOTB, and now it does not.
Offline
https://unix.stackexchange.com/question … ev-rules-d
udevadm control --log-priority=debug
journalctl -fand plug the device
udevadm control --log-priority=infoThough b/c of https://github.com/systemd/systemd/issues/39056 I assume it would even show up in the journal at an info level (as warning)
Offline
Thanks
https://0x0.st/KAJ_.txt
Offline
Doesn't seem like (this is w/ 258 and the device fails?)
Sep 22 22:05:15 DP-PC (udev-worker)[2468]: midi3: /usr/lib/udev/rules.d/50-udev-default.rules:68 GROUP="audio": Set group ID: 996
Sep 22 22:05:15 DP-PC (udev-worker)[2471]: dmmidi3: /usr/lib/udev/rules.d/50-udev-default.rules:68 GROUP="audio": Set group ID: 996
Sep 22 22:05:15 DP-PC (udev-worker)[2466]: midiC3D0: /usr/lib/udev/rules.d/50-udev-default.rules:68 GROUP="audio": Set group ID: 996
Sep 22 22:05:15 DP-PC (udev-worker)[2474]: controlC3: /usr/lib/udev/rules.d/50-udev-default.rules:68 GROUP="audio": Set group ID: 996Offline
this is w/ 258 and the device fails?
Yes. Here is a log with 257.9 and the device working for comparison (I wanted to diff it with the bad log in an attempt to find anything so some numbers and timestamps are removed)
https://0x0.st/KAyi.txt
I see a bunch of "snd_seq_midi_event:" messages that do not show up with 258
Offline
I noticed that there was a systemd update when looking at pacman.log but didn't follow up by trying to downgrade; seems like there were quite a few udev-related changes in 258 other than just the clock group. None of them jump out at me as possible causes though. I'm sure I never had any custom rules to make my interface work, either.
I assume that the MIDI device (in the audio stack) gets initialized by some combination of systemd and pipewire/pulseaudio/also (I run pipewire). Maybe something broke in that relationship with the new systemd version.
Last edited by merc68k (2025-09-22 20:50:25)
Offline
Because snd_seq_midi_event never gets loaded.
The problem might simply be the udev/hwdb
=> You could try to replace /usr/lib/udev/hwdb.* w/ the 257 version (and reboot) and if that doesn't fix it also /usr/lib/udev/rules.d
Offline
Neither replacing hwdb nor both of them worked
Offline