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

[Frank-III]

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.

[kitlangton]

I could not reproduce the hang with HEX’s audio code against isolated virtual audio: normal capture, audio suspend/resume, and audio-server disconnection all shut down cleanly. That does not cover your SOF/PipeWire hardware path. In the code, the logged stopping state follows a stop request and precedes keyboard teardown, microphone teardown, and the output-worker join, so a backtrace from the stuck process would help identify which step blocks.

Could you share:

• The exact source commit (git rev-parse HEAD in the checkout used to build it) and launch command or systemd unit’s ExecStart line, with any private values removed.
• Whether Settings was open or closed, and whether the first stopping event appeared before the sleep hook or any manual Stop/SIGTERM action.
• If you can catch it before the workaround kills it, a thread backtrace using the command below. Replace 12345 with the stuck HEX PID. GDB briefly pauses the process while attached, then detaches; if attachment is denied, please share that error instead.

gdb -q -n -batch -p 12345 \
  -ex "set pagination off" \
  -ex "set print frame-arguments none" \
  -ex "thread apply all bt" \
  -ex "detach" > hex-stuck-backtrace.txt 2>&1

Please review the backtrace for private paths or values before uploading it. No transcripts, audio recordings, full settings file, or unredacted logs are needed. Thanks for the detailed report and the offer to test.