Internet radio buffering: keep far-away listeners playing

Why listeners far from your server stall first

Distance rarely stalls a stream through lack of speed. It stalls it by making every repair slower. Take the formula in RFC 6349, throughput = window × 8 ÷ round-trip time. By our arithmetic, a 64 KB window over a 200 ms round trip still allows about 2.6 Mbps, some twenty times what a 128 Kbps stream needs. So a listener on another continent can have plenty of speed and still hear gaps.

The trouble comes when something goes missing. Radio over HTTP rides on TCP, which delivers data in order, so a lost packet holds up everything behind it until the replacement arrives, and that takes at least one round trip. A long route also tends to cross more networks, which in our reading gives congestion more places to appear. If the hold-ups last longer than the audio your listener's player has saved, they hear silence and a spinner.

Two stock Icecast settings show why bitrate matters here. These are the defaults in the project's documentation, not a statement about any host's setup, and the sums are ours.

• The burst. burst-size defaults to 64 KB, sent on connection to fill the player's reserve quickly. That is about 4 seconds of audio at 128 Kbps, but only about 1.6 seconds at 320 Kbps.
• The queue. When a listener lags behind, the server holds their audio in a queue. Past queue-size, 512k by default, they are removed from the stream. That is around half a minute of audio at 128 Kbps and about 13 seconds at 320 Kbps.

Find the weak link before you change anything

Who drops out, and when, tells you more than any setting. Match what you are hearing from listeners to a row here before you touch the bitrate.

To check a route, ask someone in the affected country to run this for you, and run it yourself as a comparison, ideally at the hour the complaints come in. Use your own listen link. The command listens for 60 seconds, then stops itself and prints one line.

# Mac or Linux
curl -s -o /dev/null --max-time 60 -w "status %{http_code}, connect %{time_connect}s, secure %{time_appconnect}s, first byte %{time_starttransfer}s, average %{speed_download} bytes/s\n" "https://YOUR-LISTEN-LINK"

# Windows (PowerShell or Command Prompt)
curl.exe -s -o NUL --max-time 60 -w "status %{http_code}, connect %{time_connect}s, secure %{time_appconnect}s, first byte %{time_starttransfer}s, average %{speed_download} bytes/s\n" "https://YOUR-LISTEN-LINK"

The first three times count up from the start, so a large first-byte figure far away and a small one nearby points to distance. For the average, multiply your bitrate in Kbps by 125 to get bytes a second: a 128 Kbps stream should read at or a little above 16,000, the extra being the opening burst. A figure clearly below that means this listener isn't receiving audio as fast as you are sending it. An average can hide a brief gap, so one good reading doesn't clear the route. The status should read 200. Anything else, or a command that ends straight away, means the link or the request failed, so fix that first: the figures say nothing about the route.

How many listeners can your stream handle?

Multiply listeners by bitrate and you have the outgoing bandwidth at that moment. These figures are our own sums, before protocol overhead, so leave a margin if you are sizing a server of your own.

On a Primcast radio plan the data your audience uses isn't counted, so you plan around two different limits instead: how many people can listen at once, and, on the paid plans, how many listener hours a month you get. A listener hour is one person listening for one hour.

Size each limit separately, because a station with sharp peaks and quiet nights uses them very differently. Here is a made-up example: 1,500 people for four evening hours and 200 for the other twenty comes to 180,000 plus 120,000, so 300,000 listener hours over 30 days. That peak and that total both fit Premium. Your panel shows how much of the month you have used, and we email you at 80% and 100%. At 100%, people already tuned in stay on, but new listeners can't join until the 1st of the next month, or until you move from Premium to Platinum.

These ceilings are firm. If your peak could pass 5,000, tell us the number beforehand and we will quote a station built for it.

Choosing a bitrate for listeners on weak connections

Pick the lowest bitrate that still sounds right for your programming. A lower rate gives every listener more room for recovery, and the sums above show what it saves them in data. The codec decides how low you can go before it shows, so here is where official guidance places each one. The last column is our suggestion.

Apple's ranges are for 44.1 kHz audio and come from a 2009 technical note it no longer updates, and RFC 6716 dates from 2012, so treat both as starting points rather than current advice. MDN lists MP3 as playing in all the major browsers, calls AAC support less predictable, and notes limits on Opus in Safari, so check its current tables against the players your audience uses. Our plan pages quote ceilings in Kbps rather than a list of live stream formats, so ask us before changing format.

As for the plans, we describe 32 Kbps as suiting speech and 128 Kbps as suiting most music. Treat 320 Kbps as room to use, not a goal: it carries 2.5 times the data of 128 Kbps to each listener. Platinum's three streams let you run your best quality alongside lighter copies for phones, and the player on every plan has a data saver for phones.

When nearby servers help, and when they don't

Nearby delivery helps when the long route is the weak link. With our radio CDN on Platinum your station stays at home in New York or Bucharest, while each listener connects to the closest of five cities, the others being Amsterdam, Miami and San Francisco. The stream crosses once from home to each city with an audience, and that city shares its single copy among everyone listening there, handing a new listener a few seconds of audio straight away. When we measured it, sound started 0.25–0.7 seconds after the player connected.

It also helps your encoder, which sends to its closest city too, and your audience when a delivery server stops answering: new connections move elsewhere nearby within roughly ninety seconds.

It won't help in these cases, so be honest with yourself before moving up:

• Your station's own server goes down. The stream stops in every city, because the delivery network is not a second copy of your station.
• Your studio line is shaky. A nearer city shortens the trip, but a dropping upload still reaches everyone. On Platinum, a backup encoder and a standby slot are the tools to look at.
• The listener's Wi-Fi or signal is the problem. The last stretch is still theirs. A lighter stream is the better answer.
• You keep reaching a listener ceiling. Platinum's limit is the one in the table above, whichever city people arrive through.
• Most of your audience is far from all five cities. Our plan page promises a quicker start and less buffering for Europe, the Americas, the Middle East, North Africa and West Asia. Asia-Pacific listeners are served from San Francisco. In our reading that may still be a long way off for many of them, so run the test from there before you decide.

If you run your own Icecast and prefer to keep it that way, our guide to setting up a relay covers that route.

Moving a growing station over, in order

1. Find out where your audience is. Premium and Platinum stats add countries and devices, so you can see which regions matter before you spend effort on them.
2. Take your laptop out of the chain where you can. Auto DJ plays from our servers on Premium and Platinum, so unattended hours no longer rely on your home connection.
3. Set your bitrate and run the test from one affected country. Keep the numbers.
4. If the route is the weak link, move to Platinum. Your panel, station page and existing links stay as they are, and a CDN link and Nearest server details appear in the dashboard.
5. Change your website player and directory listings to the CDN link at your own pace. It is a secure https:// link, with a plain http:// copy for older players.
6. Point your encoder at the Nearest server details when you are ready. Your password stays the same, though a SHOUTcast v1 encoder puts your station number in front of it, as the dashboard shows, and DJ logins get their own Nearest server block.
7. Run the same test from the same place and compare it with the numbers you kept.

Questions people ask

Is the buffering my station's fault or the listener's connection?

If everyone drops at the same moment, look at your encoder and upload first. If only one country or region has trouble, the route is the likely cause. If it's one person, on every station they try, it's their connection or device.

Would a bigger buffer in the player solve it?

It helps ride out longer gaps, at a price: a bigger reserve takes longer to fill, and in our view it only hides a route that keeps losing data. Use it alongside a sensible bitrate, not in place of one.

Does nearby delivery raise my listener limit?

No. Platinum's ceiling is 5,000 people at once wherever they connect, and its monthly allowance is 1.5 million listener hours. If you expect more than that, tell us your peak and we will quote a station to fit.