How Internet Radio Streaming Works: Buffers, Latency and Metadata
Pressing play starts a chain: encoder, server, buffer, speaker. Here is how internet radio streaming works under the hood, and what actually happens when a stream stutters or stops.
Written byice Radio FM
From the studio to the server: the encoder's job
When you press play on a station in the ice.radio.fm directory, the audio you hear has already traveled a short distance through a chain of software. The chain starts at the station, where a program takes live audio and compresses it with a codec at a chosen bitrate, the same numbers covered in our guide to bitrates.
That program is called an encoder. In the open source world, Icecast's companion tool IceS can read audio from disk or sample live audio from a sound card and encode it as it plays, according to the Icecast project. The encoded audio is then pushed continuously to a streaming server, which is the piece most people actually think of as the radio station's address.
Streams exist for one reason: they are live. Unlike a music app that feeds you individual files, a radio stream is a continuous broadcast. Every listener connected to the same stream hears the same audio at the same position, and no single listener can pause it or jump to another track, as the Icecast documentation points out. Everyone listening is tuned into the same broadcast, exactly like FM radio.
The server fans the stream out to every listener
The streaming server, almost always an Icecast or SHOUTcast instance, receives one stream from the encoder and serves it to hundreds or thousands of listeners at once. Each listener holds their own connection to the server, but they all consume the same continuous audio.
The Icecast project describes a mountpoint as the path a stream lives on, created automatically when a source connects to the server. A station can run several mountpoints at once, which is why you sometimes see the same program offered as MP3, AAC, or Opus streams from one server. The server simply keeps feeding each mountpoint to whoever is connected.
Icecast officially supports open formats like Ogg Vorbis, Opus, FLAC, and WebM, and in practice carries many MP3 and AAC streams as well. From the listener's side, the format barely matters; what matters is that the server is doing the same job as a broadcast tower, radiating one signal to everyone tuned in.
Your player and the buffer: why streams stutter less than they used to
The server is not aiming audio at your speaker directly. Your player deliberately collects several seconds of audio in advance, holds them in a short-term store called a buffer, and plays from that store while more audio keeps arriving. Browsers wait until enough media has arrived to play through without interruption before starting the sound, a behavior documented by MDN.
The buffer is a trade. A bigger buffer means a small network hiccup passes unnoticed, because the player still has audio to play while the connection recovers. A smaller buffer means the stream starts faster and stays closer to live, but any hiccup is audible as a stutter.
This is why a station can play perfectly on Wi-Fi and stutter on a weak mobile signal. The stream is still arriving, just slower than the player is consuming it, so the buffer runs dry. When that happens, the player pauses to refill it, and the gap between the station and your ears grows by however long the refill took.
Latency: why live radio is always a few seconds behind
Because of encoding, network travel, and buffering, internet radio always lags the studio by a few seconds. You are not hearing the exact moment a DJ speaks; you are hearing it several seconds after it left the building. The buffer is the main source of that delay.
The lag is usually somewhere between a few seconds and half a minute, depending on the station and player. It matters most for live events. If you are listening to a match or a news bulletin, the same event may reach a TV minutes earlier and internet radio later, simply because the path from studio to your phone is longer and includes a deliberate delay for smoothness.
Apple's HLS technology, which many stations use for browser and mobile playback, has a low latency mode designed to shrink that delay for live content. It is not available everywhere, but it shows that the industry treats lag as a fixable problem, not a law of physics.
How now playing reaches your screen: ICY metadata
The station name, artist, and track title you see on a player are not part of the audio itself. They travel alongside it as metadata, and most internet radio uses an old scheme called ICY, inherited from the early SHOUTcast days.
The mechanics are simple. The player asks the server for metadata with an Icy-MetaData request header, and the server answers with a number telling the player how often metadata arrives, typically every 8192 bytes of audio. Sandwiched between the audio blocks are tiny messages like StreamTitle='Artist - Track Name', which the player reads and shows on screen. Headers like icy-name and icy-br carry the station name and bitrate at connection time.
Directories like ice.radio.fm read this same metadata to show a now playing line on a station page. The metadata simply describes the stream the station is already broadcasting publicly; nothing is hosted or redistributed, the directory only links to the stream and plays it. Newer HLS streams use a parallel system where ID3 tags are embedded in each media segment instead of ICY blocks.
HLS: when radio comes in little segments
Alongside continuous Icecast and SHOUTcast streams, many stations now publish HLS (HTTP Live Streaming). Apple designed HLS to run on ordinary web servers and content delivery networks rather than dedicated streaming servers, and to adapt to changing network conditions on its own.
An HLS station chops audio into short segments, a few seconds each, and publishes a small playlist file that tells players which segments exist and in what order. The player fetches segments one by one over plain HTTPS, which is why HLS streams behave well inside browsers and behind firewalls and proxies that block direct audio connections.
The playlist updates as the live broadcast continues, so the player always knows what comes next. If a segment download fails, the player just tries again or fetches the next one, which is a big part of why HLS feels resilient on flaky mobile connections.
Why streams drop, and what happens next
Streams drop for a handful of recurring reasons. Your network hiccups, your phone hands off between a Wi-Fi router and mobile data, a tunnel or lossy stretch of road interrupts the connection, the station restarts its server, or the server reaches its listener limit. None of these mean the station is gone; they mean the road between it and you broke for a moment.
Different players react differently. Most web players pause, show a buffering indicator, and try to reconnect, sometimes automatically, sometimes after you click play again. HLS players recover by design, because each segment is an independent request. A robust player will quietly rejoin the stream a few seconds back from where you were, which is exactly how switching Wi-Fi networks mid-song feels like a jump backward.
When a stream keeps dropping on you, the practical fixes are the same ones radio directories have been recommending for years: move to Wi-Fi, switch to the station's lower bitrate stream, or use a dedicated radio app that retries connections harder than a browser tab does. The station itself almost never vanished while you were listening.
The short version: what matters when you listen
The chain is encoder, streaming server, player buffer, speaker. Every link adds a little delay.
The buffer is why streams survive small network hiccups, and why live content is always a few seconds behind.
Now playing text travels alongside the audio as ICY metadata, small title blocks inserted between chunks of sound.
HLS stations chop audio into segments and fetch them over plain web requests, which makes them resilient in browsers and on mobile.
A dropped stream is usually a broken connection, not a dead station. Reconnect, lower the bitrate, or switch to Wi-Fi.
All the audio comes from streams stations publish themselves. The directory links to and plays them; there is nothing to download or keep.
Frequently Asked Questions
Why does my radio keep buffering?
Buffering means the player's audio store is running dry because data is arriving slower than it plays. Common causes are a weak mobile signal, Wi-Fi congestion, handoff between networks, or a stream bitrate higher than your connection can carry. Switching to Wi-Fi or a lower bitrate stream usually fixes it.
Where does the now playing song title come from?
Stations publish song titles as metadata alongside the audio, using the ICY system: the player asks for metadata, and the server inserts small blocks like StreamTitle='Artist - Title' every few thousand bytes of audio. HLS streams embed similar ID3 tags inside each segment. The player simply reads those blocks and shows them.
Why is internet radio a little behind live?
The audio has to be encoded, travel over the internet, and sit in your player's buffer before you hear it. The buffer alone adds several seconds on purpose so small network hiccups do not cause stutters. That deliberate delay is why internet radio lags a live TV broadcast by a few seconds to half a minute.
What is the difference between Icecast and SHOUTcast?
Both are streaming servers that do the same job: receive one stream from a station and serve it to many listeners over the internet. Icecast is open source and known for supporting formats like Ogg Vorbis and Opus, while SHOUTcast is the older proprietary system whose ICY metadata scheme the whole industry still uses. Compatibility and audio format support are the practical differences.
Why does my stream stop when I switch from Wi-Fi to mobile data?
Your device kills the old network connection during the handoff, so the audio connection breaks for a moment. The stream itself keeps broadcasting; only your link to it dropped. Your player will usually try to reconnect, but the stream may restart a few seconds behind where it was, so the song may jump backward.
Is a radio stream a file I can keep?
No. A live stream is continuous audio that the station broadcasts, and you hear it in real time. Stations publish these streams publicly and the directory simply links to and plays them; there is nothing stored on your device and nothing to save after the broadcast ends. If you want a track again, you listen when it is on.
