[itz4blitz]

Summary

• Discord call playback fades into silence when the speaker cushion runs dry, and crossfades when an over-full buffer drops samples from the front, so that splice is not a click.
• Reopening the microphone or speaker (a new choice, a device that went away, or microphone permission arriving mid-call) runs on its own thread. The 20 ms tick only swaps in a device that is already open, and drops the old streams off the tick.
• Slack, Teams, Telegram, and Signal calls are unchanged. Video and screen share are unchanged.

Test plan

• cargo test -p mediad (already green on this branch)
• Discord DM call with a second account: talk, pause the network for a second, resume. No pop at the edge of the gap on either end.
• Same in a voice channel, with the other person talking continuously on a congested link. No crack when the buffer catches up.
• Mid-call, switch speaker and microphone, and unplug a headset. Speech keeps its cadence, the call stays connected, and the window stays usable.
• Mute, unmute, deafen, undeafen. No click on the boundary.
• Stay in the call for half an hour, then leave. mediad is gone within a couple of seconds.

Made with Cursor

[itz4blitz]

The playback change does what it says. next ramps the last fade frames to silence before an underrun, and trim_front blends the samples about to play into the new head before dropping the front of an over-full ring. The 20 ms tick only installs a Fresh device and sends the old streams to the device thread to drop. A route check that has not moved returns Quiet and does not reopen. Linux is green.

Two notes, neither blocks the audio change: DeviceDesk.queued is never written, so a choice made while an open is in flight waits in the controls mutex until the next tick, which is fine. The README row for #10 still says that pull request conflicts and needs a rebase; it is already on main.

I cannot approve this from the author account. I'll merge it once macOS and Windows pass on 937f0e5.