Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Apple Silicon: speakersafetyd's post-resume PCM reinit wedges/crashes wireplumber, leaving audio stuck muted (no resume-fix, unlike wifi/HID/NVMe)
Reported by doomnote · filed Sep 8, 2026Closed upstream on 2026-10-08 by the bot omarchybot, as not planned.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
What happened
On a MacBook Pro 16" M2 Pro (Mac14,10 / apple,j416s / apple,t6020), audio
gets stuck after lid-close resume: the panel shows muted, unmute does
nothing, and the volume keys are dead. This isn't a real ALSA/hardware mute
(amixer -c1 sget Speaker still shows [on]) — wireplumber itself is wedged
and no longer answers wpctl/pactl requests at all.
This happened 3 times in one session (08:37:37, 10:32:49, 11:31:24), and is
reproducible across resumes, not a one-off.
Root cause (as far as I can establish)
Every time, wireplumber logs this right at resume:
wp-proxy: (../wireplumber/lib/wp/proxy.c:459):wp_proxy_get_bound_id:
runtime check failed: (wp_object_get_active_features (WP_OBJECT (self))
& WP_PROXY_FEATURE_BOUND)
at the same moment speakersafetyd logs its own resume workaround:
speakersafetyd[838]: WARN Expected 4096 samples, got 1664
speakersafetyd[838]: WARN Suspend detected!
speakersafetyd[838]: WARN Reinitializing PCM to work around kernel bug...
At 10:32:49 this actually took wireplumber down with SIGSEGV
(coredumpctl info 1459, package wireplumber 0.5.17-1, `pipewire
1:1.6.8-1, speakersafetyd 2.0.1-1, kernel 7.1.6-1-1-ARCH`). The crashing
thread's PC (0xfffef1a6b718) is unmapped in the core (confirmed via `info
proc mappings`) — a wild jump, not a normal unresolved-symbol frame. The one
resolvable frame in the chain is pw_resource_remove
(libpipewire-0.3.so.0+0xadee0, resolved locally via nm/addr2line since
Arch's debuginfod doesn't cover Arch Linux ARM builds). That, plus the
wp-proxy runtime-check failure logged in the same instant, points at a
use-after-free/stale-pointer race in wireplumber's object teardown when
speakersafetyd tears down and recreates the PCM device out from under it. At
other resumes it didn't crash, just got stuck spinning at ~29% CPU, alive but
unresponsive to every client.
I believe the underlying memory-safety bug is upstream in WirePlumber/
PipeWire, not something to fix inside Omarchy. But the trigger is entirely
inside Omarchy's own choices: install/hardware/apple/audio.sh is what
installs and enables speakersafetyd as part of Omarchy's Apple Silicon
audio stack, and Omarchy already ships resume-race fixes for this exact
class of Apple Silicon problem — fix-wifi-resume.sh,fix-suspend-nvme.sh, fix-asahi-hid-race.sh — but has no equivalent for
the race speakersafetyd's own resume workaround causes in wireplumber.
Suggested fix
A resume-hook service in the same family as omarchy-wifi-resume-fix.service:
wait briefly after resume, check whether wireplumber answers wpctl status,
and restart it for the active session's user if not. I've been running
exactly this locally (omarchy-audio-resume-fix.service //usr/bin/omarchy-audio-resume-fix, After=suspend.target etc., mirroringfix-wifi-resume.sh's structure) and it reliably self-heals within ~10s of
resume. Happy to share the script if useful as a starting point forinstall/hardware/apple/.
Steps to reproduce
- Apple Silicon Mac running Omarchy with the Apple audio stack
(speakersafetyd + wireplumber) installed.
2. Play or open any audio, close the lid, wait for suspend, reopen.
3. Check wpctl status / try to unmute — often hangs or shows no response.
4. journalctl -u speakersafetyd and journalctl --user -u wireplumber
around the resume timestamp show the log lines above.
Filed by Claude Sonnet 5 via Claude Code.
View raw text
### What happened
On a MacBook Pro 16" M2 Pro (Mac14,10 / apple,j416s / apple,t6020), audio
gets stuck after lid-close resume: the panel shows muted, unmute does
nothing, and the volume keys are dead. This isn't a real ALSA/hardware mute
(`amixer -c1 sget Speaker` still shows `[on]`) — wireplumber itself is wedged
and no longer answers wpctl/pactl requests at all.
This happened 3 times in one session (08:37:37, 10:32:49, 11:31:24), and is
reproducible across resumes, not a one-off.
### Root cause (as far as I can establish)
Every time, wireplumber logs this right at resume:
wp-proxy: (../wireplumber/lib/wp/proxy.c:459):wp_proxy_get_bound_id:
runtime check failed: (wp_object_get_active_features (WP_OBJECT (self))
& WP_PROXY_FEATURE_BOUND)
at the same moment speakersafetyd logs its own resume workaround:
speakersafetyd[838]: WARN Expected 4096 samples, got 1664
speakersafetyd[838]: WARN Suspend detected!
speakersafetyd[838]: WARN Reinitializing PCM to work around kernel bug...
At 10:32:49 this actually took wireplumber down with SIGSEGV
(`coredumpctl info 1459`, package `wireplumber 0.5.17-1`, `pipewire
1:1.6.8-1`, `speakersafetyd 2.0.1-1`, kernel `7.1.6-1-1-ARCH`). The crashing
thread's PC (`0xfffef1a6b718`) is unmapped in the core (confirmed via `info
proc mappings`) — a wild jump, not a normal unresolved-symbol frame. The one
resolvable frame in the chain is `pw_resource_remove`
(`libpipewire-0.3.so.0+0xadee0`, resolved locally via `nm`/`addr2line` since
Arch's debuginfod doesn't cover Arch Linux ARM builds). That, plus the
wp-proxy runtime-check failure logged in the same instant, points at a
use-after-free/stale-pointer race in wireplumber's object teardown when
speakersafetyd tears down and recreates the PCM device out from under it. At
other resumes it didn't crash, just got stuck spinning at ~29% CPU, alive but
unresponsive to every client.
I believe the underlying memory-safety bug is upstream in WirePlumber/
PipeWire, not something to fix inside Omarchy. But the trigger is entirely
inside Omarchy's own choices: `install/hardware/apple/audio.sh` is what
installs and enables `speakersafetyd` as part of Omarchy's Apple Silicon
audio stack, and Omarchy already ships resume-race fixes for this exact
class of Apple Silicon problem — `fix-wifi-resume.sh`,
`fix-suspend-nvme.sh`, `fix-asahi-hid-race.sh` — but has no equivalent for
the race speakersafetyd's own resume workaround causes in wireplumber.
### Suggested fix
A resume-hook service in the same family as `omarchy-wifi-resume-fix.service`:
wait briefly after resume, check whether wireplumber answers `wpctl status`,
and restart it for the active session's user if not. I've been running
exactly this locally (`omarchy-audio-resume-fix.service` /
`/usr/bin/omarchy-audio-resume-fix`, `After=suspend.target` etc., mirroring
`fix-wifi-resume.sh`'s structure) and it reliably self-heals within ~10s of
resume. Happy to share the script if useful as a starting point for
`install/hardware/apple/`.
### Steps to reproduce
1. Apple Silicon Mac running Omarchy with the Apple audio stack
(speakersafetyd + wireplumber) installed.
2. Play or open any audio, close the lid, wait for suspend, reopen.
3. Check `wpctl status` / try to unmute — often hangs or shows no response.
4. `journalctl -u speakersafetyd` and `journalctl --user -u wireplumber`
around the resume timestamp show the log lines above.
Filed by Claude Sonnet 5 via Claude Code.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.