How online audio streaming works

A radio stream looks simple from the outside: press play and sound comes out. Underneath, long-lived audio over HTTP behaves quite differently from loading a web page. This article explains the moving parts in plain terms. It describes general principles of the technology, and the technology page covers the specific setup of this project.

A page is short, a stream is long

A normal web request ends within a fraction of a second. A live stream keeps one connection open for minutes or hours. The server keeps sending small chunks of audio, and the browser keeps decoding and playing them. Any hiccup on the way, from a Wi-Fi handover to a locked phone, can end the connection without either side noticing straight away.

Buffering: the cushion between network and ears

Players keep a few seconds of audio in memory. A larger buffer survives short network drops but adds delay; a smaller one is more immediate but fragile. For a radio-style experience, a few seconds of delay is irrelevant, so favouring stability is the sensible trade.

Why browsers pause audio

• Autoplay rules. Browsers generally require a user gesture, such as a tap, before audio may start. This is why the first press of play is always needed, especially on iPhone.
• Power saving. Background tabs and locked screens are throttled to save battery, which can interrupt a connection.
• Network changes. Switching from Wi-Fi to mobile data creates a new network path, and the old connection usually dies.

Designing for interruption

Because interruptions are normal, a good player treats them as an expected event. It detects that playback has stalled, offers a clear way to resume and, where the platform allows, reconnects automatically. Media Session support lets the operating system show the station name and standard play and pause controls on the lock screen.

Serving it safely from home

Self-hosting raises a security question: how do visitors reach a machine at home without opening ports on the router? A tunnel service makes an outbound connection from the server to a provider, which then forwards public traffic through it. The server is never directly exposed, and the provider also absorbs a share of unwanted traffic.

Checklist for a reliable stream

• Test on real phones, not only desktop browsers.
• Make resuming one tap.
• Show clearly what is playing, so a reconnect is not confusing.
• Keep the interface light, because the listener mostly wants audio.

More practical tips are on the mobile page, and the full story of how these lessons were learned is in the development history.

Formats and bitrates in plain terms

Audio is compressed before it is sent. A higher bitrate means better quality and more data per second; a lower one saves bandwidth and works better on a weak mobile connection. Common web formats such as MP3 and AAC are supported almost everywhere, which is why they are a safe choice for a stream meant to run in any browser. The listener never sees these choices, but they decide whether the stream is stable on a train or only on home Wi-Fi.

Metadata: showing what is playing

A stream is only sound, so information such as the station name or current title has to travel separately. A player can request this from the server at intervals, or it can be embedded in the stream. Keeping the display in sync with the audio is a small but real problem: if the buffer holds ten seconds of audio, the title shown must match the audio being heard, not the audio being sent.

Why a refresh is not the same as a reconnect

When a listener reloads a page, a simple player starts over and may even land on a different point in the broadcast. A well-designed system keeps the broadcast state on the server and lets any client rejoin it. This is the difference between a playlist, which belongs to the listener, and a station, which belongs to the server. The development history describes how this problem showed up in practice.

Testing on real devices

Emulators do not reproduce battery saving, a lock screen or a switch from Wi-Fi to mobile data. Useful tests include locking the phone for several minutes, switching networks, putting the browser in the background and opening another audio app. Each of these exposes a different failure, and each has a different fix. See also the mobile page.

Glossary

• Buffer: audio held in memory ahead of playback.
• Bitrate: data per second of audio.
• Reconnect: opening a new connection after a drop.
• Tunnel: an outbound connection that lets a home server be reached without open ports.