[BUG] Intermittent non-silent WAV with no recognized speech on Linux; same mic later works without process restart

Bug

Handy 0.9.7 on Ubuntu 24.04 (GNOME Wayland, PipeWire, AMD SoundWire mic) intermittently saves non-silent 16-kHz mono WAVs that contain no recognisable current speech. The user played the failed recordings and heard background/older sounds rather than their spoken test phrase. Handy produced five consecutive empty transcripts, then produced normal transcripts from the same microphone/model in the same running process. The content of those failed WAVs has not been independently identified; in particular, byte-for-byte replay of earlier audio has not been proved.

This is an intermittent report, not a deterministic reproducer. The goal here is to preserve a failed/successful pair and request the right capture diagnostic for the next occurrence, rather than assert a PipeWire, VAD, or model root cause.

Controlled offline comparison (same model/backend, saved WAVs)

Both WAVs are Handy recordings from one session, PCM 16-bit mono 16000 Hz. Audio is private and is not attached. The commands below use handy -f to bypass the mic and paste pipeline.

$ handy -f recordings/handy-1790925310.wav --model handy-computer/parakeet-unified-en-0.6b-gguf/parakeet-unified-en-0.6b-Q8_0.gguf
Transcription completed in 0.44s for 18.24s of audio
Transcription result is empty
model=... backend=Vulkan0 audio=18.24s load=232ms best=440ms rtf=41.45x
text:

$ handy -f recordings/handy-1790925673.wav --model handy-computer/parakeet-unified-en-0.6b-gguf/parakeet-unified-en-0.6b-Q8_0.gguf
Transcription completed in 0.39s for 8.10s of audio
Transcription result: [REDACTED by reporter: private speech]
model=... backend=Vulkan0 audio=8.10s load=212ms best=389ms rtf=20.82x
text: [REDACTED by reporter: private speech]

The failure WAV is not digital silence. I decoded 16-bit little-endian PCM (od -An -v -t d2 -j 44 <WAV>) and computed rms=sqrt(sum(sample²)/count) with awk:

failed:  n=291840 zero_pct=0.05 rms=2063.8 peak=20804 (16-bit PCM)
success: n=129600 zero_pct=0.22 rms=3259.6 peak=32768 (16-bit PCM)

This measures signal energy, not speech quality or source identity. The saved files contain different energy profiles; that alone cannot identify the fault.

Source cross-check during failure

Handy's active stream was on source 60, the system's actual mic, not an output monitor:

$ pactl get-default-source
alsa_input.pci-0000_c5_00.5-platform-amd_sdw.HiFi__Mic__source
$ pactl list source-outputs short
1299  60  1298  PipeWire  float32le 1ch 44100Hz

The user separately recorded six seconds with timeout 6s pw-record --target 60 --rate 16000 --channels 1 --format s16 /tmp/handy-mic-check.wav and heard their current speech on playback. This was adjacent in time, not simultaneous, so it rules out a permanently dead mic but not an intermittent source/routing fault.

Timeline / process evidence (local time UTC+05:30)

• 12:45:11: Handy saved an 18.24s WAV with 291840 samples; preview had 0 updates/0 chars; offline decode above is empty.
• 12:45:15: next recording started in the same Handy instance. By 12:50:54 it had 61.44s captured, 14 preview updates and nonempty transcript; the next 8.10s recording at 12:51:13 also succeeded.
• Main process handy --start-hidden PID 356685 (AppImage child PID 356708) started at 12:16:57 and stayed alive throughout. A handy --start-hidden invocation was made before recovery, but Handy is single-instance; this command forwards to the existing app and raises its window. Whether that action affected capture is unknown. The main process was not restarted.
• The on-disk vad_enabled setting was changed during debugging, but log entries still show VAD at stop during both failed and successful runs; do not assume this change took effect in the live process.

Expected and diagnostic question

Both Handy and pw-record should capture current speech from source 60. Which low-overhead signal diagnostic (per-recording levels, cpal stream counters, PipeWire link/target changes, resampler state) would best distinguish wrong/stale capture from unintelligible-but-current audio on the next occurrence?

Related but not exact duplicates: #1899 is digital silence from a sink monitor (this WAV has substantial signal and the default was the mic); #2113 returns zero samples after a stall (ours saved 291840 samples); #1349 requires a PipeWire restart (ours recovered while the main process stayed alive). No root cause is asserted here.