For most of internet radio's history, going live meant a computer. You needed a desktop encoder, an audio interface, and a desk to put them on. That requirement quietly disappeared: a modern iPhone has more than enough processing headroom to capture a microphone, mix it against a music bed, encode the result to MP3 in real time and hold a network socket open for hours. What was missing was a source client that speaks the protocols radio servers actually use.
This guide covers the whole path — what an Icecast or Shoutcast server expects from a phone, which settings genuinely affect your sound and stability, and what to check when a connection refuses to open. The examples use BroadcastSelf for iPhone and iPad, but the protocol logic applies to any iOS source client.
What your phone actually has to do
A source client has one job: deliver a continuous stream of encoded audio to a server that will fan it out to listeners. On iOS that breaks into five stages, all running on the device:
- Capture — the microphone is read continuously as raw PCM inside an audio session configured for background audio, so the stream survives a locked screen.
- Playback — MP3 files are decoded from local storage, with ID3 tags supplying the title and artist you will push as metadata.
- Mix — per-channel gain, faders, mute and a final output limit combine voice and music into one signal.
- Encode — the mix is compressed to MP3, typically with the LAME encoder, at your chosen bitrate.
- Send — the client performs the source handshake for your protocol, then pushes encoded frames over a TCP socket until you stop.
Everything to the left of the server runs on the phone. The server is separate infrastructure that you own or rent — a broadcasting app is the studio, not the transmitter. That distinction trips up more first-time broadcasters than any technical setting: no app can hand you an audience without a server behind it.
Getting a server: your three realistic options
1. A managed streaming host
The fastest route. You pay a monthly fee and receive a control panel plus the six values every source client needs: server type, host, port, mount path, source username and source password. Managed hosting handles bandwidth, uptime and usually a listener statistics page. The trade-offs are a listener cap, a bitrate cap on cheaper plans, and — worth knowing before you buy — some hosts block access to the admin interface from outside their own panel, which means no external encoder can read your live listener count.
2. Self-hosted Icecast on a VPS
A $5–6/month virtual server gives you unlimited mounts, no listener cap beyond your bandwidth, and full log access. It takes about an hour to set up the first time. We have a step-by-step walkthrough in self-hosting an Icecast 2 server on a VPS.
3. Icecast on your own machine, for testing
Running Icecast on a laptop on the same Wi-Fi is the best way to learn. Point the phone at the laptop's local IP address, connect, and open the stream URL in VLC. You get the entire feedback loop with no money spent and no public exposure — ideal for rehearsing before your first real show.
Icecast or Shoutcast? Pick before you type anything
The two families use completely different source handshakes, so choosing the wrong type guarantees a failed connection no matter how correct the rest of your details are.
| Setting | Icecast v2 | Shoutcast v1 | Shoutcast v2 |
|---|---|---|---|
| Mount path | Required, e.g. /stream |
Not used | Used |
| Username | Required, usually source |
Not used | Not used |
| Password | Source password | Source password | Source password |
| Public stream URL | http://host:port/mount |
http://host:port/;stream.mp3 |
http://host:port/mount |
Shoutcast v1 authenticates with the password alone — no mount, no username — which is why a good source client hides those two fields the moment you select it. If you are still weighing the two platforms, Icecast vs Shoutcast compares them properly.
The six values you need, and the two that go wrong
Every connection reduces to six pieces of information:
Host → ic.example.com (no http://, no port, no trailing slash)
Port → the SOURCE port, often 8000
Mount path → /stream (Icecast only, must start with /)
Username → source (Icecast only)
Password → your SOURCE password
Two of these account for the overwhelming majority of failures.
The port. Hosting panels display several ports and only one of them accepts a source connection. The web or admin port will let you log in to a browser dashboard and will reject your encoder every time. When in doubt, ask your host explicitly for the source port.
The password. Icecast and Shoutcast both maintain separate source and admin passwords. The source password is what your phone uses to send audio. The admin password belongs to the control panel and is only relevant if you want live listener statistics. Pasting the admin password into your encoder produces an authentication rejection that looks, unhelpfully, exactly like a typo.
Any competent iOS client should offer a connection test that performs a real handshake and shows you the server's own error text rather than a generic failure. Use it before every first broadcast to a new server — it turns a five-minute mystery into a five-second diagnosis.
Bitrate: the setting listeners actually hear
Bitrate is the single biggest lever on both quality and cost, because bandwidth consumption is simply bitrate multiplied by concurrent listeners.
| Bitrate | Best for | Notes |
|---|---|---|
| 32–64 kbps | Talk, news, sermons | Voice survives low bitrates far better than music. Saves serious bandwidth at scale. |
| 96 kbps | Mixed talk and music | A sensible compromise when your plan is bandwidth-limited. |
| 128 kbps | Music stations | The default recommendation. Good fidelity, universally supported, modest bandwidth. |
| 192–320 kbps | Music-first, audiophile | Only when your server plan permits it and your listeners have the connection to match. |
Two constraints matter more than taste. First, many hosting plans cap the bitrate they accept and will refuse a source that exceeds it — a rejection that reads as a mysterious connection failure. Second, higher bitrates are less forgiving on an unstable uplink: 320 kbps over patchy mobile data will stutter where 96 kbps would have held.
Buffer size: the setting that decides whether you stay on air
The streaming buffer is how much encoded audio the client holds before pushing it out. It is a direct trade of latency against resilience, and on a phone it matters more than on a desk, because a phone moves through cell handovers, lifts and dead spots.
- ×1 — too small for almost any real network. Expect dropouts.
- ×2 — only on a fast, stable, fixed Wi-Fi connection.
- ×4 — the sensible default for the vast majority of shows.
- ×8 — mobile data, weak signal, or anything broadcast while moving. Adds a little delay and rides out a great deal of jitter.
Pair a larger buffer with automatic reconnection. Networks fail; the question is whether the client notices and re-establishes the stream by itself, or whether you find out twenty minutes later that nobody has heard you. A well-built client also remembers that a manual stop is deliberate and never fights it.
Mixing voice and music on a touchscreen
A radio mix is two signals in conversation. The controls that make that workable on a phone are the same ones on a physical desk, just drawn differently:
- Gain sets how hot each source is before it reaches the mix. Set this first: raise the mic gain until the level meter peaks healthily without pinning.
- Faders set how much of each channel goes into the final mix. This is what you ride during a show.
- Level meters tell you what your listeners are getting before they get it — a buried music bed or a distorting mic is visible seconds before it is audible to anyone else.
- An output limit caps the combined signal so voice and music peaking together cannot clip. Around 85% leaves useful headroom.
- Channel locks matter specifically on touchscreens: a fader you cannot nudge with your palm is a fader that will not embarrass you mid-sentence.
The standard talk-over move is to drop the music fader to roughly a third, speak, then bring it back. Practise it once before you go live; it is the single gesture that separates a show that sounds produced from one that sounds accidental.
Metadata: the part people forget
Metadata is the "now playing" text your listeners see in their player and that directory listings index. A source client should push the track title and artist to your server on every song change, read from the file's ID3 tags. Two practical consequences follow: untagged files show a filename where a song title belongs, and a station name set once in your output settings is what identifies your stream everywhere it appears. Both are worth five minutes before launch. Our stream metadata guide goes deeper.
Music you are allowed to broadcast
You cannot re-broadcast Spotify or Apple Music. Those catalogues are DRM-protected and licensed for personal listening, not transmission, and no legitimate app will route them to a server. Broadcast files you own or are licensed to play — and remember that owning a file is not the same as holding the public performance rights, which in most territories come from a collecting society. Check what your country requires before you build an audience on a foundation you cannot keep.
In practice this means putting MP3 files on the device. On iOS that is the Files app: On My iPhone → your broadcasting app's folder, or drag them across from a Mac in Finder. Files land there and appear in the app with no import step.
Battery, heat and the practicalities of a long show
A live broadcast keeps the microphone, encoder and radio active continuously. That is a genuine load: a two-hour show will visibly drain a phone, and a phone that is charging while streaming in a warm room will get warm. For anything longer than about an hour, keep the device on power, and consider airplane mode plus Wi-Fi if you are broadcasting from a fixed location — it removes cellular radio churn and one whole class of interruption.
When it will not connect: a diagnostic order
Work through these in sequence rather than changing several things at once:
- Server type — Icecast and Shoutcast handshakes are not interchangeable. The wrong one always fails.
- Host format — hostname or IP only. No
http://, no port appended, no trailing slash. - Port — the source port, confirmed with your host.
- Password — the source password, not the admin password.
- Mount path — Icecast only, starts with
/, and must match what the server is configured to accept. - Bitrate — below your plan's ceiling.
- Simultaneous sources — a second encoder still logged in on the same mount will knock you off. Disconnect it.
If audio connects but nobody can hear you, the problem has moved from the network to the mixer: check the mic channel is active rather than muted, that its fader is up, and that the level meter is actually moving. A meter that never moves means iOS is not handing the app microphone access — check the permission in iOS Settings and close any other app that might be holding the microphone.
A realistic first broadcast
Set aside twenty minutes, not five. Install your source client, enter the six values, and run the connection test until it succeeds. Open the resulting stream URL in VLC on another device and confirm you can hear yourself — this is the step people skip and then wonder about. Add a handful of tagged MP3 files, play one, and check the title appears in your player. Practise the talk-over once. Then start for real.
The technology stopped being the obstacle some time ago. A phone in your pocket can hold a broadcast-quality stream for hours to an audience anywhere in the world. What remains is the part that was always the hard bit: having something worth saying, and turning up regularly enough that people learn when to listen.