Skip to content

Fix duplicate dmix ipc_key collisions in asound.conf#1102

Closed
SteveMicroNova wants to merge 1 commit into
mainfrom
fix/asound-unique-dmix-ipc-keys
Closed

Fix duplicate dmix ipc_key collisions in asound.conf#1102
SteveMicroNova wants to merge 1 commit into
mainfrom
fix/asound-unique-dmix-ipc-keys

Conversation

@SteveMicroNova

Copy link
Copy Markdown
Contributor

What does this change intend to accomplish?

All twelve loopback dmix devices in asound.conf share 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 / snd_pcm_dmix_open: unable to open slave depending 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

  • Have you tested your changes and ensured they work? (in production on a real AmpliPi since 2026-06-08)
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?
  • If applicable, have you updated the CHANGELOG?
  • Does your submission pass linting & tests? (config-only change; happy to fix anything CI flags)

NOTE: This was originally pr #1095, I just screwed up the git history and didn't have the rights to fix it in that PR due to not owning the branch origin. Thank you to stamateviorel for this work!

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 #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>
@SteveMicroNova
SteveMicroNova requested a review from linknum23 June 25, 2026 18:56
@SteveMicroNova

Copy link
Copy Markdown
Contributor Author

This may no longer be necessary as stamateviorel has just rebased their PR #1095, once tests are completed this is liable to be deleted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants