Podcast / on-demand
Plain HTTP MP3 or AAC. CDN-cacheable, range-requests for seek. No protocol overhead. Latency irrelevant (on-demand). Right answer for any pre-recorded content. Works perfectly with resume-from-timestamp and chapter markers—listeners can jump to any point in the file without re-downloading.
The simplicity of HTTP streaming makes it ideal for podcasts. Listeners can use any standard audio player, and your infrastructure just needs basic HTTP servers or a content delivery network. RSS feeds link directly to audio files, and clients automatically detect file duration and seekable positions via HTTP range headers. This approach costs nothing to scale beyond server bandwidth.
Most podcasting platforms use this model: Spotify, Apple Podcasts, and YouTube Music all cache the same HTTP URLs behind their platforms. Analytics and CDN footprint are straightforward. No need for specialized streaming servers or protocol negotiation. The downside is that you cannot stream audio before the entire file is downloaded to the client buffer—progressive download means listeners must wait or pre-download.
Live radio (one-way, large audience)
HLS or DASH with audio-only manifests. 6-30s latency depending on segment size. CDN-scaled. Right for shoutcast-style live broadcast to thousands. Or Icecast for legacy stations. Both scale globally via CDN edge nodes, buffer to smooth network jitter, and support adaptive bitrate selection for bandwidth constraints.
HLS (HTTP Live Streaming) and DASH (Dynamic Adaptive Streaming over HTTP) divide the live audio stream into small chunks—typically 2–10 seconds each—and serve them via HTTP. A manifest file tells the client which chunks to fetch next. This approach leverages HTTP caching and CDN infrastructure, so one stream can be served to millions of listeners without dedicated streaming servers. The client buffers several segments ahead, masking network hiccups.
Icecast, by contrast, uses the older HTTP/1.1 streaming model where a client makes a single request and receives a continuous stream of bytes. It works but does not scale as well because each connection ties up server resources. However, Icecast excels at ultra-low latency configurations if tuned carefully, and it powers many community and legacy radio stations worldwide because it requires minimal infrastructure and runs on cheap hosting.
For broadcast radio over the internet, HLS or DASH is the modern standard. Choose HLS if your audience is primarily Apple/mobile; choose DASH for cross-platform compatibility. Latency is typically 6–30 seconds depending on segment duration and buffer depth—acceptable for radio but not for interactive use.
Conversational (two-way)
WebRTC. <300ms latency. Direct or TURN-relayed. Doesn't scale to broadcast (1:1 or small-group). Right for calls, agents, live interviews where back-and-forth matters.
WebRTC (Web Real-Time Communication) is the protocol of choice for any conversation where low latency and bidirectional audio matter. It uses UDP under the hood for speed, with fallback to TCP if necessary. The browser or app peers communicate directly or via a TURN relay server if they are behind different NATs. Audio is typically codec-agnostic but Opus is the standard—it compresses well and handles varying network conditions.
The protocol includes built-in jitter buffers, packet loss recovery, and automatic gain control to normalize loudness. Echo cancellation removes feedback when two participants are in the same room. These features are not trivial to implement from scratch, which is why WebRTC is standard for video conferencing, voice calls, and real-time collaboration tools. Latency is sub-300ms under normal conditions, enabling natural conversation flow.
The tradeoff: WebRTC does not scale to broadcast. Each listener requires a separate connection to the broadcaster, and media servers must handle per-connection processing. For 1:1 calls or small group discussions (under 10 participants), WebRTC is ideal. For live radio to thousands, use HLS or DASH instead.