Linux: dictation listener parks in 'stopping' after resume from suspend — process alive, no crash (suspected audio re-init race)

Environment

• HEX: 2.1.6, built from main @ 2026-08-28 via scripts/install-linux.sh
• OS: Arch Linux, kernel 7.1.5-arch1-2
• Compositor: Hyprland (wlroots Wayland), X11 absent
• Hardware: Xiaomi Book Pro 14 — Intel Meteor Lake, SOF audio (sof-adl-* firmware), Goodix fingerprint (unrelated), Vulkan inference on iGPU
• Audio: PipeWire with ALSA compat; device selected as "Default Audio Device"
• Input/paste: evdev listener + wtype/wl-copy, all per the Linux guide

Behavior

After resume from suspend (s2idle), the dictation listener ends up in stopping within seconds and never recovers. The process stays alive the whole time — no crash, no coredump, nothing in the system journal. In the parked state it also ignores SIGTERM; recovery requires SIGKILL + relaunch.

It looks like a race with device re-initialization at resume:

• After some resumes, a relaunch minutes later still parks in stopping ~8 seconds after session_started
• After other resumes, the identical relaunch stays listening for days
• The same binary, same session, nondeterministic outcome per resume

Log timeline (live.ndjson, transcript text redacted)

Failure:

Aug 31 22:48:09  kernel: PM: suspend exit
Aug 31 22:51:26  {"kind":"session_started"}
Aug 31 22:51:26  {"kind":"state","state":"listening"}
Aug 31 22:51:34  {"kind":"state","state":"stopping"}     ← parked, ~3 min after resume

Healthy resume on the same machine:

Sep 01 06:59:10  kernel: PM: suspend exit
Sep 01 07:0x     session_started → listening → dictating → pasted   (fine)

process.log contains nothing at these moments — only periodic unrelated update-check warnings.

Suspect

The audio DSP (SOF) re-initializes late after resume on this hardware. If the listener opens its Default Audio Device stream during the broken window, it stops itself without a retry path. Consistent with the intermittency and with the listener (not the process) being the component that gives up.

Workaround currently in place

A systemd-sleep hook SIGKILLs and relaunches HEX after every resume (with a settle delay plus a verify-and-retry pass). This masks the bug day-to-day but obviously isn't a fix.

Happy to provide unredacted state-only logs (no transcripts), any extra diagnostics, or to test a build with additional logging around the resume path.

Start by reproducing with scripts/install-linux.sh and the reported session_started → listening → stopping timeline, then inspect the Linux listener's resume and audio re-initialization path. Done means a post-resume listener remains recoverable instead of parking in stopping, validated with state-only logs on the Arch/Wayland/PipeWire setup.