Live radio has a cruel property: nobody cares about the transmission you missed three seconds ago. They care about what's on the air right now. We learned that the hard way when a handful of mobile clients on flaky LTE started falling behind on inbound WebSocket frames. The server kept dutifully enqueueing audio. The clients kept dutifully falling further behind. Eventually everyone sounded like they were broadcasting from a time machine set to "yesterday."
Conference-call stacks solve this with jitter buffers, NACKs, and a general attitude of "we'll get there eventually." CB radio is not a conference call. Half-duplex keyed transmit means bursts of media, not a continuous bidirectional stream. When a listener's socket buffer fills up, the humane move is not to preserve every byte for forensic replay — it's to drop stale frames and snap back to the present.
We landed on a latest-frame-wins posture: if the client can't keep pace, older chunks get discarded in favor of whatever just arrived. That sounds brutal until you sit in a busy channel and realize delayed audio is worse than a tiny glitch. Operators notice a half-second hitch. They do not notice — and actively resent — hearing a punchline after the room has already moved on.
The interesting part isn't the philosophy; it's where you apply it. Backpressure has to be visible on both sides of the wire. The server needs a sane story for congested sessions without punishing the whole channel. The client needs to recover without requiring a full page reload — because nothing kills community radio faster than "turn it off and on again" as a daily ritual.
We're still tuning the ergonomics around slow networks and background tabs. But the lesson stuck: treat live channel audio like a radio signal, not a file download. If you're behind, you catch up by skipping ahead — not by playing every frame you missed while the band kept talking without you.