Broadcasting on unreliable internet: a practical guide
Advice written for symmetric fibre is useless on a connection that drops twice an hour. Here is what actually helps when the network is the constraint.
Most streaming guidance assumes a stable connection with plenty of upload headroom. If yours is a mobile connection shared with a building full of people, or a line that drops whenever it rains, the standard advice does not survive contact with reality. This is what does.
Upload is the number that matters, and it is not the advertised one
Broadcasting sends data out, so your upload speed is the constraint — and on most consumer connections it is a fraction of the download figure in the advertisement. Test it during the hour you actually broadcast, not on a quiet weekday morning. A Sunday at 10am and a Wednesday at 2pm are different networks.
You want measured upload to be comfortably more than your stream needs, because you are sharing the line with everyone else on it.
Choose a bitrate you can hold, not the best you can reach
The instinct is to pick the highest quality the connection managed in a test. This is the wrong instinct. A stream at a bitrate you can sustain through the bad minutes sounds far better than a higher one that stutters, because a dropout is much more destructive to listening than a modest reduction in fidelity.
- Speech-only content is entirely comfortable at a low bitrate — voices need much less than music.
- Music benefits from more, but the gains flatten out quickly.
- If in doubt, go one step down. Nobody has ever stopped listening because a stream was 96 kbps rather than 128.
Prefer a wired connection, then a dedicated one
In order of reliability: ethernet, then Wi-Fi you control, then mobile data, then shared public Wi-Fi. If the broadcasting device can be plugged in, plug it in — Wi-Fi introduces a variable you cannot see and cannot fix while it is happening.
Where mobile data is the only option, keep the broadcasting device off everything else. A phone that is streaming and also syncing photos is competing with itself.
Plan for the drop, because there will be one
The question is not whether the connection will fail but what happens when it does. Two things matter: that the broadcast reconnects on its own rather than waiting for someone to notice, and that listeners are not simply dumped.
The listener apps handle their side automatically — a dropped stream is retried with a backoff for as long as the listener still intends to listen, so a brief outage resolves itself without anyone pressing play. Worth knowing, because it means a ten-second dropout usually costs you nothing.
Have a fallback you can reach in thirty seconds
The realistic failure is the connection dying properly, mid-broadcast, with the room still going. Decide in advance:
- A second device on a different network, already set up and signed in.
- A phone with mobile data ready to tether, tested beforehand.
- Someone other than the person leading who is watching the stream and can act.
The most useful preparation is not equipment. It is that somebody in the room is watching the broadcast rather than assuming it is fine.
Record locally as well
Whatever happens to the stream, a local recording gives you something to publish afterwards. A broadcast that failed at minute twenty is a disappointment; a broadcast that failed at minute twenty with no recording is a lost service.
Start broadcasting free