Online server reliability

(Disclaimer: I reworked the BBC’s iPlayer encoding system for radio, including significant increases in bitrate and audio quality)

Internet radio depends on an online server being reliable, and all the links in the increasingly complicated internet broadcast chain also being similarly reliable. Live radio is particularly difficult to carry on the internet, since you can’t buffer “ahead of time” (since it’s live), and therefore any drop in any of the connections between you and the server will cause a break in your reception.

This is something that shouldn’t affect on-demand listening (like BBC iPlayer or YouTube) since these systems normally download a good amount of the programme beforehand and store this in the memory of your device. Ironically, this means that on-demand or file-based broadcasts (like Pandora in the US or similar services here) are rather more reliable.

Additionally, your device may be too busy doing other things to maintain a good connection or to decode the audio – this can happen on PCs but happens to a great degree on mobile phones. My top-of-the-range phone is incapable of receiving internet audio and decoding it while also sending that audio via Bluetooth, for example: stutters and gaps are all over the music, which is highly irritating.

So, the answer to your question isn’t, really, one of servers – but one of the whole chain. And that’s yet another boring reason why broadcast radio is a significantly better way to reach audiences than the internet.

There will always be an improvement in reliability, at the same bitrate, when using AAC-based streaming technologies compared to their MP3 counterparts. This is down to nothing more complicated than AAC codecs having better compression (and sound quality, at lower bitrates at least) than MP3, meaning less data is being transferred. Indeed, many major media outlets now use this for their streaming.

However, as James says, there are a lot of factors that affect server reliability. The server type and the codec in use is only one of them.

There will always be an improvement in reliability, at the same bitrate, when using AAC-based streaming technologies compared to their MP3 counterparts. This is down to nothing more complicated than AAC codecs having better compression (and sound quality, at lower bitrates at least) than MP3, meaning less data is being transferred.

Hi, Dave. No, “at the same bitrate” means that there is the same amount of data being transferred. A 32k AAC+ stream is exactly the same bitrate as a 32k MP3 stream.

In actual fact, an AAC+ stream may be less reliable than a MP3 stream at the same bitrate, since the decoding device (your computer, phone, etc) has to do more work to decode the AAC+ stream: therefore increasing the likelihood of overloading the processor and therefore getting stutters and gaps. Given radio’s unique place as “the multitasking medium”, users are more likely to also be using a computer or phone for something else that is also processor-intensive.

Hi, Dave. No, “at the same bitrate” means that there is the same amount of data being transferred. A 32k AAC+ stream is exactly the same bitrate as a 32k MP3 stream.

Yes, I appear to have mixed myself up (and made a gaffe) there. The point that I was trying to make that, to achieve the same quality of audio, you would be able to run AAC at a lower bitrate than MP3 because of its improved compression. For some reason in type-up I’ve suggested the same bitrate.

Your point about doing more work is valid, and I hadn’t thought of that.

I might add as well, that this happens on usually the same stations, no matter what the actual device is. I have an iPod Touch with the TuneIn app, that I use for some internet listening, and I have a dedicated internet radio that I also use.

The issues always seem to crop up with the same stations. I rarely get problems with WNYC, WGBH, WETA or any number of other stations, it tends to be with stations like RTE Lyric FM, Radio Plymouth, Palm FM, Radio Exe and Jack FM Bristol. Now being aware that Radio Plymouth has suffered from numerous server problems, I wondered if the server might be the problem with other stations.

One extreme example of what I’m talking about happened about 1am one night. I’d been listening to Radio Plymouth, which is a 128kbps WMA stream on the TuneIn app, with no real problems. I then switched to RTE Lyric FM, which if memory serves is a 32kbps MP3 stream, and the buffering was almost every 30 seconds, it was horrible. No change in equipment or state, just changed the stream, and the difference was marked.

Any thoughts why that should be?

No change in equipment or state, just changed the stream, and the difference was marked. Any thoughts why that should be?

Although all manner of things in the chain could be the cause like James says, I’d hazard a guess that the upstream from the studio might often be the weak link if they use ADSL broadband. It can be surprisingly limited bandwidth with some ISP’s. I wonder how many stations take the effort to enforce some QoS to ensure their upstream to the streaming provider is protected from other traffic like running backups, staff watching videos etc etc? (I know that job never came to the top of the list with a community station I helped run!)

Glyn makes a really good point. If you expect the reliability of your internet stream to be as good as possible, given that listeners expect it to be as good as traditional broadcast platforms (whether it can be or not is another matter), you really have to treat the chain as broadcast as much as you can. The fact that from the point it leaves you to the end-user’s ISP is rather fuzzy, unless you or your content delivery partner has a direct peering arrangement, is more of a problem long-term.

You have to hope the internet does what it wasn’t really meant for. But it’s no hope if you can’t get your data to your ISP’s gateway with the outside world, which means prioritising traffic across your link to the exchange.

We had a problem a few years back at our online university student radio station where by anyone listening after 5pm found it near impossible to keep connected. It also effected anyone on any computer in the university.

I kept hounding our I.T. (information services) team, and eventually (6 months or so later- why it took so long we will never know) it was discovered that there was a university wide network backup going on from 5pm that assumed everyone had basically gone home, so it could use nearly the entire bandwidth of the entire university to back up… Incredible!

This was eventually replaced by an incremental system peaking at 4am and all our problems were solved…..