molluskandClaude Opus 4.8
8e0b4c16ec
Codex's xhigh re-review of the prior cpal RT fixes confirmed W2/W3/W7/W4-diag addressed (and validated the reserve-first ring-publish ordering), but found the W1/W6 start-handshake fixes were partial. This closes the holes: - B1 (P1): wait_for_stream_start checked the liveness flag before the error code, so a callback that ran then failed in the same WASAPI cycle could still report Ok on a dead stream. Readiness now (a) treats the error as terminal — checked first each loop AND re-checked before returning Ok — and (b) requires MIN_START_CALLBACKS (2) completed callbacks, not one, so a fire-once-then-die stream is caught by the error/timeout path. The liveness signal is now a callback counter (AtomicUsize) instead of a one-shot bool. - B2 (P2): on the inner STREAM_START_TIMEOUT the owner sent Err and THEN dropped the stream; since cpal Stream::drop joins its (wedged) WASAPI worker and finish_start joins the owner on that Err, start_*/stop could still hang past the backstop. The owner now drops the stream BEFORE reporting Err, so a wedged drop withholds the Err and lets finish_start's timeout branch detach. - B4 (P3): the two timeouts didn't compose — a slow-but-valid setup plus a slow first callback could exceed the 6s backstop and be falsely failed. Raised FINISH_START_TIMEOUT to 10s (setup budget + callback wait + cleanup slack) and corrected the comment. Deferred (logged in review-2026-06-19-cpal-rt-audit.md): B3 (orphan-thread tombstone accounting on a permanent >10s driver wedge — rare, non-crashing, needs a slot-state redesign) and B5 (choose_config picking a bounded supported rate for an oddball sub-8k/over-384k default-rate device — rare; the safety validation already prevents the panic/spin). Verified: Linux cargo test --lib 326/0, clippy --all-targets clean; windows-gnu cargo check --lib --tests --bins clean; windows-gnu release peerspeak.exe links. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>