Fix duplicate dmix ipc_key collisions in asound.conf#1095
Conversation
All twelve loopback dmix devices shared ipc_key 1028. dmix instances with
the same ipc_key collide on one shared-memory segment, so opening a
loopback playback device intermittently fails with EINVAL ('unable to
open slave') depending on open order - the same signature as micro-nova#957. The
player then crash-loops; on our production unit the LMS player flapped
189 times/day until the keys were made unique. Also pins the 8ch dmixer
slave rate to 48000 so its format can't drift from the loopbacks.
Running in production on a stock 0.4.10 system since 2026-06-08 with
zero loopback open failures since.
Signed-off-by: Stamate Viorel <stamate.viorel@gmail.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| period_size 1024 | ||
| buffer_size 4096 | ||
| channels 8 | ||
| rate 48000 |
There was a problem hiding this comment.
Is setting this fixed rate required? I know this is the default rate of the device but I'm not sure what the implications of fixing this rate rate.
There was a problem hiding this comment.
Not strictly required, and happy to drop it. It's defensive rather than a fix: without an explicit rate, the first client to open the dmix sets the slave rate for every other loopback, so a stream that opens at 44100 would reconfigure the shared buffer and force resampling on everything else. Pinning it to 48000 (the DAC's native rate, which is also dmix's default here) just makes that explicit so no single client can move it.
That said, it's a separate concern from the ipc_key collision this PR is really about. If you'd rather keep the change minimal, I'll pull the rate line out and leave just the unique-key fix.
| pcm.lb1 { | ||
| type dmix | ||
| ipc_key 1028 | ||
| ipc_key 1029 |
2 participants
What does this change intend to accomplish?
All twelve loopback dmix devices in
asound.confshareipc_key 1028. dmix instances with the same ipc_key collide on one shared-memory segment, so opening a loopback playback device intermittently fails withEINVAL/snd_pcm_dmix_open: unable to open slavedepending on open order and which zones are active. The player on that source then crash-loops: on our production unit the LMS player flapped 189 times/day until we made the keys unique. The log signature is identical to #957 (lb4c ... unable to open slave ... EINVAL), so I believe this is that issue's root cause. The patch gives every loopback dmix a unique ipc_key and pins the 8ch dmixer slave rate to 48000 so its format can't drift from the loopbacks.Running in production on a stock 0.4.10 unit since 2026-06-08 with zero loopback open failures since (previously several per day).
Checklist