cpal 0.17's ALSA worker reports `alsa::poll() returned POLLERR` and polls
again immediately, without snd_pcm_recover: a PCM left in XRUN/SUSPENDED/
DISCONNECTED (CPU starvation at a track change on a Pi, a suspend, a pulled
cable) becomes a tight loop that never plays again until the stream is
dropped. rodio's default callback eprintln!s every one of them, which is the
POLLERR flood in the issue. The System default and PipeWire routes installed
no error callback at all, and nothing rebuilt a wedged stream.
- New qbz-audio::stream_health: classify (Wedged vs Transient), a flood
limiter (one log line per 5s window with a suppressed count), a wedge
latch, and one shared error_callback installed on every CPAL route
(System default x4, PipeWire, ALSA) and the legacy player path.
- The audio thread checks the wedge latch at the TOP of its loop, every
iteration, not in the recv_timeout Timeout arm: under QConnect the
renderer-state command flow keeps recv returning Ok(...) and the Timeout
arm barely runs, which left a wedged worker spinning a core for ~22s.
On a wedge it drops the stream (joining cpal's worker), and when playing
rebuilds and resumes at the current position; a second wedge within a 10s
backoff releases the device and stops instead of looping.
Bit-perfect paths (ALSA Direct, DSD, WASAPI) are untouched; they never use
cpal's worker. The low-memory profile from 2.1.0 already addressed the exit
137 OOM; this is the separate flood/wedge half.
Verified on a Pi 4B + HiFiBerry DAC+ over the System default route with a
192 kHz 835 MB track and SIGSTOP-induced wedges: rebuild+resume in ~40 ms,
auto-recovery after the backoff, release+stop on a repeat wedge, and 7
POLLERR log lines instead of a flood. qbz-audio 125 and qbz-player 139 tests
pass; new stream_health and wedge_recovery tests included.
cc
vicrodh
9fdf53c3ea