The Signal

Icecast, HLS, and the Buffer That Lives Between Studio and Listener

Two streaming architectures, one latency trade-off — and the answer depends on whether the caller is on hold or the score just changed.

Piece 2 of 5 in The SignalOpen the section

Icecast, HLS, and the Buffer That Lives Between Studio and Listener — The angle is the latency trade-off: a phone-in show and a sports result need different answers.
Photo: Brett Sayles / Pexels

The Difference That Matters at Airtime

Icecast works by pushing a continuous audio stream — typically MP3 or AAC — from a server directly to each connected listener. The connection is persistent, the latency is low, often under ten seconds, and the architecture is elegantly simple. It is also fragile: a single server handles every concurrent connection, and when traffic spikes or the server fails, listeners drop simultaneously. SomaFM built its early infrastructure around Icecast, as did many community and independent stations that needed an open-source, zero-licence solution. For a station with a few thousand concurrent listeners and no phone-in format, that model holds.

HLS — HTTP Live Streaming, standardised by Apple and documented in RFC 8216 — works differently. The audio is segmented into small files, typically two to ten seconds each, which a CDN distributes to listeners on request. The player fetches successive segments; if one is delayed, it fetches the next from a closer edge node. Latency climbs — typically 20 to 45 seconds in standard HLS implementations — but resilience scales with the CDN, not with any single server. A station pushing simultaneous streams to hundreds of thousands of listeners during a breaking-news moment routes around failure almost transparently.

An adult broadcast engineer at a studio patch bay, cables and labelled ports in close frame — A patch bay is the last analogue decision in a mostly digital chain, and the point at which a fault is isolated by hand.
Photo: 將將王 / Pexels

That latency gap is not a technical nuisance — it is an editorial decision embedded in infrastructure. A phone-in show in which a caller hears the presenter on FM while streaming on a separate device will notice a 30-second gap between speech and reply. A football result announced on air arrives half a minute late to the streaming audience, which, in a social-media environment, is enough for the result to appear on a listener's phone before the presenter speaks it.

Every channel strip is a gain stage. What leaves the desk is already the product of decisions taken before any transmission standard applies.

Photo: Scott Platt / Pexels

On the scale

The record carries no single date, so the scale carries a bracket in place of a numeral.

Where this sits

The Signal

Codecs, bitrates, transmission chains, loudness standards, and the physical infrastructure a broadcast depends on.

All 5 pieces

The latency spectrum

The Signal

Icecast (push stream): typically under 10 seconds end-to-end
Standard HLS: typically 20–45 seconds
Low-Latency HLS (LL-HLS): under 5 seconds when correctly configured
Standard broadcast FM delay: 2–4 seconds (processing and transmission only)

When latency is the editorial question

The Signal

Phone-in formats: callers monitoring both FM and stream hear the gap as a double-voice effect; low latency required
Sports results: a 30-second HLS lag allows results to reach listeners via social media before the presenter announces them
Music and talk: latency largely irrelevant; CDN resilience and scale dominate the decision

The broadcast industry's response has been segmented. Large commercial groups — iHeartMedia, Audacy before its Chapter 11, the BBC — moved their primary streams to HLS precisely because CDN resilience at scale outweighed latency cost for most content. The BBC's streaming infrastructure, documented in its own engineering publications, uses HLS as the default delivery path for BBC Sounds. Low-Latency HLS, an extension to RFC 8216 published by Apple and incorporated into the standard, reduces delivery latency to under five seconds by partially exposing segments before they are complete — narrowing the gap without abandoning CDN distribution.

Icecast survives where it fits: listener-funded stations, community licensees, and niche internet services where direct server connection is still manageable and the intimacy of near-live audio is the product. The buffer is not a bug either protocol needs to fix. It is the price each charges for what it delivers.