fix(desktop): huddle playout drops good audio on ~half of all ticks

[sboily]

Problem

Huddle voice sounds constantly choppy on some machines. The playout queue high-water is 4 frames, but the rodio Player queue naturally oscillates between 1 and 6 during perfectly healthy playback — the device callback consumes in bursts that beat against the 10 ms producer tick. So skip_one() fires on roughly half of the ticks, and each hit cuts 10 ms out of the speech.

Easy to see live: stderr spams playout queue high-water … dropping oldest frame at depth 4-5 the whole time a peer is speaking. Measured with a standalone feeder (one 10 ms buffer appended every 10 ms, default MacBook output): Player::len() >= 4 on 49% of appends.

Fix

• High-water 4 → 16 frames (160 ms, still under NetEq's max_delay_ms of 200 ms), well above the natural oscillation.
• When it trips (a real consumer stall), drain to 8 frames in one go, bounded by count: skip_one() only takes effect on the device callback thread, so a while len() > target loop spins while the output stream is starting (hit this at huddle join).

Testing

• Before/after on a machine that reproduced it: drops go from near-constant to zero in steady state, and voice is clean by ear.
• cargo fmt, cargo clippy, and the 92 huddle unit tests pass.
• No new unit test: the behavior needs a real audio device callback. The measurement is a ~40-line standalone feeder — happy to share it in a comment if useful.

[sboily]

For context: I found this while building a Python client library for Buzz (text + voice huddles): https://github.com/sboily/buzzkit. I was bridging an AI voice agent into a huddle, and its clean synthesized speech made the constant 10 ms cuts much easier to hear than regular mic audio — that's what led me to trace the receive path down to this queue.

[sboily]

I did some test with other users and they also have a choppy sound. Could be great if you have time to review because sound is not useable currently.

[sboily]

Closing this as superseded — the root cause is now fixed on main, by a better approach than the one proposed here.

b29c8cd ("feat(desktop): redesign the Huddle experience", #4281, merged 2026-08-04) replaced the whole drift-bounding mechanism in desktop/src-tauri/src/huddle/playout.rs. PLAYOUT_QUEUE_HIGH_WATER no longer exists; the current thresholds are:

const PLAYOUT_QUEUE_RECOVERY_START: usize = 10;
const PLAYOUT_QUEUE_RECOVERY_END: usize = 4;
const PLAYOUT_QUEUE_EMERGENCY_HIGH_WATER: usize = 30;
const PLAYOUT_RECOVERY_SPEED: f32 = 1.02;

The steady-state hard drop is gone. Producer-vs-device clock drift is now absorbed by playing 2% faster with hysteresis (engages at depth 10, disengages at 4), and skip_one() survives only as an emergency bound at 30 frames. The new code names the problem this PR reported, in as many words: "A shallow hard drop used to remove entire 10 ms chunks and create audible discontinuities."

Point by point against what this PR argued:

• Threshold 4 sits inside the queue's natural 1–6 oscillation, so the drop fired on ~half of all ticks. Nothing fires below depth 30 now. At depth 1–6, update_playout_recovery() is a complete no-op — zero frames discarded in steady state.
• One drop per tick never converges, since producer and consumer run at the same rate. The drain is now a genuine consumer-rate increase (2%, ~20 ms of excess resorbed per second) rather than a discard, so it does converge.
• A while len() > target loop would spin, because skip_one() only takes effect on the device callback thread. No such loop on main.

That makes #4281 strictly better than what's proposed here: this PR still shed 8 frames at once whenever the raised threshold of 16 tripped, whereas the current code discards no audio at all under normal conditions.

Rebasing isn't worth it — both hunks collide head-on with the rewritten block, and carrying them forward would reintroduce the hard drop that #4281 deliberately removed.

Thanks to whoever picked this up in the redesign. Leaving the original measurement here for the record, since it's what pinned the natural queue range: with a standalone 100 × 10 ms-buffers/s feeder on a default MacBook output, Player::len() >= 4 on 49% of appends, oscillating between 1 and 6 during perfectly healthy playback.