Problems with ALSA MIDI raw devices after upgrading to kernel 5.14

[lentferj]

I installed 5.14 kernel from this source (https://github.com/geoffreybennett/scarlett-gen2/releases) on Debian Buster to test out the better USB audio latency.

I found that both Bitwig and Ardour6 cannot start anymore when using ALSA MIDI raw devices. In Bitwig the sound engine keeps crashing and Ardour6 doesn't start at all when choosing raw devices.

In Ardour6 I see this:

ALSA lib rawmidi_hw.c:100:(snd_rawmidi_hw_params) SNDRV_RAWMIDI_IOCTL_PARAMS failed: Invalid argument
ardour-6.9.0: rawmidi.c:268: snd_rawmidi_open_conf: Assertion `err >= 0' failed.
Aborted

I also tried to access devices directly with amidi, same result.

$ amidi --dump -p hw:5
ALSA lib rawmidi_hw.c:100:(snd_rawmidi_hw_params) SNDRV_RAWMIDI_IOCTL_PARAMS failed: Invalid argument
amidi: rawmidi.c:268: snd_rawmidi_open_conf: Assertion `err >= 0' failed.
Aborted

I manually upgraded alsa-lib and alsa-utils to 1.2.5, but I still have the same problem:

$ which amidi
/usr/bin/amidi
lentferj@ts-d20:~$ ls -l /usr/bin/amidi
-rwxr-xr-x 1 root root 57064 Sep 19 18:34 /usr/bin/amidi
lentferj@ts-d20:~$ ldd /usr/bin/amidi
    linux-vdso.so.1 (0x00007ffc50c9b000)
    libasound.so.2 => /usr/lib/libasound.so.2 (0x00007f9c97c85000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9c97b02000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9c97afd000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9c97adc000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9c9791b000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9c97911000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f9c97dc0000)
lentferj@ts-d20:~$ ls -l /usr/lib/libasound.so.2
lrwxrwxrwx 1 root root 18 Sep 19 18:29 /usr/lib/libasound.so.2 -> libasound.so.2.0.0
lentferj@ts-d20:~$ ls -l /usr/lib/libasound.so.2.0.0
-rwxr-xr-x 1 root root 5242136 Sep 19 18:29 /usr/lib/libasound.so.2.0.0
lentferj@ts-d20:~$ uname -a
Linux ts-d20 5.14.0 0000021 SMP Mon Aug 30 00:46:47 UTC 2021 x86_64 GNU/Linux

lentferj@ts-d20:~$ amidi -l
Dir Device Name
IO hw:2,0,0 Saffire 6USB2.0 MIDI 1
IO hw:3,0,0 Neutron(1) MIDI 1
IO hw:4,0,0 Pulse2 MIDI 1
IO hw:5,0,0 LPK25 MIDI 1
lentferj@ts-d20:~$ amidi --dump -p hw:5
ALSA lib rawmidi_hw.c:100:(snd_rawmidi_hw_params) SNDRV_RAWMIDI_IOCTL_PARAMS failed: Invalid argument
amidi: rawmidi.c:256: snd_rawmidi_open_conf: Assertion `err >= 0' failed.
Abgebrochen 

When booting back to a 5.10 kernel the problems disappear.

I also reported this on the Ardour Tracker ( https://tracker.ardour.org/view.php?id=8800 ).

[diwic]

I wonder if this is because older alsa-lib versions might leave params->mode uninitialized, causing a bogus value to be submitted instead of the expected 0. This is in turn causing kernel 5.14 to return an error.

Can the kernel somehow detect an older alsa-lib in order to ignore the params->mode field? Or is there some other way out of this?

[perexg]

The snd_rawmidi_open_conf() calls only snd_rawmidi_params_default() which does not initialize the reserved space in the rawmidi params struct. I fixed this in a1e91720ccfe24611e841213fc0641436ae7d453. It's a bug since 2001.

[lentferj]

I manually applied this patch to the 1.2.5 sources and can confirm that amidi direct access, Ardour6 and Bitwig 4.0.1 now work again with raw midi devices. Thanks a ton for the quick fix.

diff -ru alsa-lib-1.2.5/include/sound/uapi/asound.h alsa-lib-1.2.5_patched/include/sound/uapi/asound.h
--- alsa-lib-1.2.5/include/sound/uapi/asound.h  2021-05-27 23:30:16.000000000 +0200
+++ alsa-lib-1.2.5_patched/include/sound/uapi/asound.h  2021-09-19 21:49:41.973912234 +0200
@@ -733,6 +733,7 @@
    size_t buffer_size;     /* queue size in bytes */
    size_t avail_min;       /* minimum avail bytes for wakeup */
    unsigned int no_active_sensing: 1; /* do not send active sensing byte in close() */
+   unsigned int mode;      /* For input data only, frame incoming data */  
    unsigned char reserved[16]; /* reserved for future use */
 };

diff -ru alsa-lib-1.2.5/src/rawmidi/rawmidi.c alsa-lib-1.2.5_patched/src/rawmidi/rawmidi.c
--- alsa-lib-1.2.5/src/rawmidi/rawmidi.c    2021-05-27 23:30:16.000000000 +0200
+++ alsa-lib-1.2.5_patched/src/rawmidi/rawmidi.c    2021-09-19 21:15:28.059054399 +0200
@@ -154,6 +154,8 @@
    params->buffer_size = page_size();
    params->avail_min = 1;
    params->no_active_sensing = 1;
+   params->mode = 0;
+   memset(params->reserved, 0, sizeof(params->reserved));
    return 0;
 }

diff -ru alsa-lib-1.2.5/src/rawmidi/rawmidi_local.h alsa-lib-1.2.5_patched/src/rawmidi/rawmidi_local.h
--- alsa-lib-1.2.5/src/rawmidi/rawmidi_local.h  2021-05-27 23:30:16.000000000 +0200
+++ alsa-lib-1.2.5_patched/src/rawmidi/rawmidi_local.h  2021-09-19 21:18:41.925960003 +0200
@@ -48,6 +48,7 @@
    size_t buffer_size;
    size_t avail_min;
    unsigned int no_active_sensing: 1;
+   int params_mode;
 };

 int snd_rawmidi_hw_open(snd_rawmidi_t **input, snd_rawmidi_t **output,

[diwic]

Thanks for the quick testing.

Do we need to take additional measures in order not to break existing userspace (i e older alsa-lib), or are we happy with telling people they need to upgrade alsa-lib (or apply either https://github.com/alsa-project/alsa-lib/commit/a1e91720ccfe24611e841213fc0641436ae7d453 or https://github.com/alsa-project/alsa-lib/commit/95eb312fade1908a2c944e9de4626c0ff60b2203 ) if they want rawmidi to start working again?

[perexg]

+ memset(params->reserved, 0, sizeof(params->reserved));

@lentferj - Only this line is sufficient also for the older library. It's not required to add the mode field (which is allocated from the reserved space anyway).

Do we need to take additional measures in order not to break existing userspace (i e older alsa-lib), or are we happy with telling people they need to upgrade alsa-lib (or apply either a1e9172 or 95eb312 ) if they want rawmidi to start working again?

Ideally, we should add a new ioctl like SNDRV_PCM_IOCTL_USER_PVERSION, but for the rawmidi API and if the user space does not confirm the new API knowledge, it should not be activated. @tiwai - FYI

[perexg]

Proposed kernel patch: https://lore.kernel.org/alsa-devel/20210920083538.128008-1-perex@perex.cz/

[vincenzoml]

Hi, since I am trying to test the focusrite 18i8 fixes of v5.14, but need raw midi working for that, am I correct in thinking the easiest way to get a kernel with both raw midi and focusrite gen3 alsamixer channels, is to apply this patch:

https://lore.kernel.org/alsa-devel/20210920083538.128008-1-perex@perex.cz/

to the 5.14.6 sources? Or is there a better way?

[perexg]

https://lore.kernel.org/alsa-devel/20210920083538.128008-1-perex@perex.cz/

to the 5.14.6 sources? Or is there a better way?

The mentioned kernel patch or the alsa-lib fix https://github.com/alsa-project/alsa-lib/commit/a1e91720ccfe24611e841213fc0641436ae7d453 should work. Pick one as you like.

[spurkopf]

Could you be so friendly and publish a new release, as the elimination of rawmidi represents a significant restriction?

[diwic]

@spurkopf A patch has already been added to linux-stable, and it will be part of Linux 5.14.10.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/core/rawmidi.c?h=linux-5.14.y&id=12d50801497235956fb3760be8530f4e44e4ce67

[spurkopf]

Good to know, thank you! I didn't know that it would be resolved through the kernel. Then I'll have to be patient.

[perexg]

Fixed now in kernel and in c932c1e7abd07b7f5a402891a344d676c10275a5 .

[ensonic]

I still get crashes in Bitwig sometimes and right now get crashes with a java applcation

java: rawmidi.c:256: snd_rawmidi_open_conf: Assertion `err >= 0' failed.

I am on kernel 5.15.3 (opensuse tumbleweed). Often restarting apps a couple of times is enough (are they just lucky and get clear memory then?).

[perexg]

Oops. There's small error in the kernel code:

https://syzkaller.appspot.com/x/log.txt?x=11791d89b00000

https://lore.kernel.org/alsa-devel/20211218123925.2583847-1-perex@perex.cz/