Linux ALSA: Excessive use of open files on /dev/snd/controlC? devices

[agraef]

This is on a Manjaro system running pipewire with the corresponding alsa, jack, and pulseaudio modules, and the audio api set to ALSA in the audio prefs.

The symptom being that if you change, e.g., the sample rate in the audio prefs a couple of times, it eventually exceeds the number of open files (ulimit -n), so that a subsequent attempt to save the prefs fails with a "too many files" error. The cause becomes apparent by running lsof -p on the pid of the purr-data process:

purr-data 1890116   ag   1u  unix 0x000000009af1378b      0t0 11263268 type=STREAM (CONNECTED)
purr-data 1890116   ag   2u  unix 0x000000009af1378b      0t0 11263268 type=STREAM (CONNECTED)
purr-data 1890116   ag   3u   CHR             116,12      0t0      960 /dev/snd/controlC0
purr-data 1890116   ag   4u   CHR              116,7      0t0      906 /dev/snd/controlC1
purr-data 1890116   ag   5u   CHR             116,14      0t0      985 /dev/snd/controlC2
purr-data 1890116   ag   6u   CHR             116,16      0t0     5363 /dev/snd/controlC3
purr-data 1890116   ag   7u   CHR             116,20      0t0     1001 /dev/snd/controlC4
purr-data 1890116   ag   8u   CHR             116,24      0t0     1009 /dev/snd/controlC5
purr-data 1890116   ag   9u   CHR             116,26      0t0     1016 /dev/snd/controlC6
purr-data 1890116   ag  10u   CHR             116,28      0t0     1033 /dev/snd/controlC7
purr-data 1890116   ag  11u   CHR             116,30      0t0     1251 /dev/snd/controlC8
purr-data 1890116   ag  12u   CHR             116,12      0t0      960 /dev/snd/controlC0
...
purr-data 1890116   ag 307u   CHR             116,12      0t0      960 /dev/snd/controlC0
purr-data 1890116   ag 308u   CHR              116,7      0t0      906 /dev/snd/controlC1
purr-data 1890116   ag 309u   CHR             116,14      0t0      985 /dev/snd/controlC2
purr-data 1890116   ag 310u   CHR             116,16      0t0     5363 /dev/snd/controlC3
purr-data 1890116   ag 311u   CHR             116,20      0t0     1001 /dev/snd/controlC4
purr-data 1890116   ag 312u   CHR             116,24      0t0     1009 /dev/snd/controlC5
purr-data 1890116   ag 313u   CHR             116,26      0t0     1016 /dev/snd/controlC6
purr-data 1890116   ag 314u   CHR             116,28      0t0     1033 /dev/snd/controlC7
purr-data 1890116   ag 315u   CHR             116,30      0t0     1251 /dev/snd/controlC8
...
purr-data 1890116   ag 376u   CHR             116,12      0t0      960 /dev/snd/controlC0
purr-data 1890116   ag 377u   CHR              116,7      0t0      906 /dev/snd/controlC1
purr-data 1890116   ag 378u   CHR             116,14      0t0      985 /dev/snd/controlC2
purr-data 1890116   ag 379u   CHR             116,16      0t0     5363 /dev/snd/controlC3
purr-data 1890116   ag 380u   CHR             116,20      0t0     1001 /dev/snd/controlC4
purr-data 1890116   ag 381u   CHR             116,24      0t0     1009 /dev/snd/controlC5
purr-data 1890116   ag 382u   CHR             116,26      0t0     1016 /dev/snd/controlC6
purr-data 1890116   ag 383u   CHR             116,28      0t0     1033 /dev/snd/controlC7
purr-data 1890116   ag 384u   CHR             116,30      0t0     1251 /dev/snd/controlC8
purr-data 1890116   ag 386u   CHR              116,9      0t0      952 /dev/snd/pcmC0D0c
purr-data 1890116   ag 387u   CHR              116,8      0t0      951 /dev/snd/pcmC0D0p
...

The number of open files grows very quickly until it reaches the 1023 mark, at which point, at least with the default ulimit -n setting of 1024 on my system, the maximum number of open files is exhausted:

purr-data 1890116   ag 1015u   CHR             116,12      0t0      960 /dev/snd/controlC0
purr-data 1890116   ag 1016u   CHR              116,7      0t0      906 /dev/snd/controlC1
purr-data 1890116   ag 1017u   CHR             116,14      0t0      985 /dev/snd/controlC2
purr-data 1890116   ag 1018u   CHR             116,16      0t0     5363 /dev/snd/controlC3
purr-data 1890116   ag 1019u   CHR             116,20      0t0     1001 /dev/snd/controlC4
purr-data 1890116   ag 1020u   CHR             116,24      0t0     1009 /dev/snd/controlC5
purr-data 1890116   ag 1021u   CHR             116,26      0t0     1016 /dev/snd/controlC6
purr-data 1890116   ag 1022u   CHR             116,28      0t0     1033 /dev/snd/controlC7
purr-data 1890116   ag 1023u   CHR             116,30      0t0     1251 /dev/snd/controlC8

This happens after at most 21 sample rate changes + Apply on my system, at which point I can't save the prefs with Ok any more, getting this error message in the Pd console instead:

[21] Opened Alsa Client 129 in:4 out:4
error: /home/ag/.purr-data/user.settings: Too many open files
... click the link above to track it down, or click the 'Find Last Error' item in the Edit menu.

That error message comes from sys_initsavepreferences() in s_file.c, so the issue is on the C side.

I don't remember seeing this before, so this might be an issue related to pipewire's ALSA backend. But then I usually don't change my sample rate all that often, and normally I'm using Purr Data's Jack backend.

The bug only happens when using the ALSA backend, the Jack backend seems to work fine. I suspect that it's actually an issue with our ALSA backend, which doesn't seem to do much in the way of closing devices before reopening them. :) Maybe the issue can be cured by backporting vanilla's recent fixes in the audio backends (s_audio.c et al) which we don't have in Purr Data yet.