molluskandClaude Opus 4.8
5bd32250a5
The playback RT callback pinned the PipeWire buffer to exactly one 1024-frame quantum (the 2026-05-31 crackle fix). That is only correct when the machine's clock.quantum is 1024 — on hardware running quantum 512 or 2048 the pinned slice mismatches the device's per-cycle demand and the crackle returns. We just shipped a release to a friend whose quantum is unknown, so this was P1. Fix: enable the pipewire `v0_3_49` feature (exposes Buffer::requested(), the graph's per-cycle quantum) and fill exactly that many frames each callback via a new pure `frames_to_produce()` seam, with a safe ≤1024 fallback when the graph reports 0 (never the whole slice — over-pulling past the ring depth is the original crackle). Relax the Buffers size pin from a hard 1024 to a generous 8192-frame max so the mapped slice fits any plausible quantum; requested(), not the buffer size, now governs per-cycle output. Verified locally with `pw-metadata clock.force-quantum` + audio_probe at forced quanta 512/1024/2048: each shows `underrun +0` steady, `quantum=` matching the forced value, and callbacks/s ≈ rate/quantum — proving requested() is live (the health line would otherwise read the 1024 fallback). +4 unit tests on frames_to_produce (148 lib tests, clippy --all-targets clean). Still pending (field test): one real desktop<->dopedart call through the fix. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>