This is something that has come up time and time again now, and with Amazing Radio going online-only with nothing but a single Shoutcast server streaming one format at one bitrate, now seemed like a good time to write about online streaming of radio stations.
Let’s start by briefly looking at real broadcast operations – on FM and AM we try and maximise coverage (within our license), maximise compatibility, and of course we want to add as much value as we can with metadata like RDS (and now things like RadioDNS). We’re trying to reach as many people as possible, with as little fuss as possible, and trying to give people the best possible service.
This is not what many broadcasters do with their online offerings, which is a real shame, considering the potential that many stations have. So what constitutes a best-effort service? What makes life easier for listeners, and how can you make your station’s output as widely available as possible? I’m just going to skim over the technology here and break things down. I’m also going to discuss briefly what we’ve done with the streams at Insanity Radio 103.2 FM, and how we’ve worked them into apps and our new Radioplayer implementation.
When we’re streaming audio we’re concerned with the components in this stream of data:
- Audio leaves studio/switcher to be broadcast
- Computer captures and encodes the audio, then payloads it
- Computer sends stream of payloaded and encoded audio data to a distribution server
- Client computer asks distribution server for a copy of an audio stream
- Client begins streaming provided audio data, depayloads and decodes audio, and plays it to a user
There’s a lot of moving parts here. The key elements to bear in mind are the encoder, the distribution server, and the client.
Audio Capture and Processing
The old adage “garbage in, garbage out” is always particularly relevant when dealing with audio processing and encoding systems – ideally you should be dealing with raw PCM audio data in your playout system and using good quality sound cards on all your machines at a suitable sample rate (48kHz) and bit depth (16 bit or higher). Assuming we have good audio reaching the system we need good software with excellent real-time performance. The Linux operating system with a real time kernel is perfect for the job. Linux also offers a wide choice of encoding tools – the two most popular for radio broadcasting are liquidsoap and darkice. Linux is also stable for long periods of unattended operation, ideal for our needs.
Processing audio in software can help when no or limited hardware processing is available to produce loudness consistency. There are various audio tools available for Linux that can be used either with liquidsoap directly or with the JACK Audio Connection Kit library in conjunction with darkice or liquidsoap – LADSPA plugins, Jamin, louderbox, JackEQ, JackRack, you name it, there’s a tool. Loudness normalisation can be done with very little additional configuration – literally one or two lines of code in a liquidsoap configuration file in some cases. Giving your listeners consistent audio loudness is really important, and can help give your station that professional feel. Liquidsoap even comes built-in with several multiband compressors and companders – it’s a crime not to use them if you have no outboard processing.
Bandwidth and Bitrates
Not all clients are equal. I’m going to assume that you have more than £15 a month income as a station and can thus afford a Virtual Private Server with a 100Mbps connection from which to stream, and that your station is not overly bandwidth-constrained locally. Streaming one bitrate is great, if all your clients are on the same sort of connection. Actually, they’re not. 128kbps is a common bitrate for single-stream stations. This is way too high for mobile devices, and low enough to be annoyingly low-quality to anyone listening on wifi or a wired connection at home. Who is this stream for? Well, not many people will find it ideal. What’s the answer? Provide many streams!
Let’s talk briefly about distribution servers. Shoutcast is a commonly chosen server. It is an option, but it’s far from the only option, and it’s closed source and tricky to set up and configure. A simpler and more powerful option is Icecast, widely used and easy to set up and configure. Either will do, realistically, but Icecast has in my books a much better record for stability and scalability.
Okay, back to our clients. Let’s say we have extremely limited computational resources – we only have one computer to do the encoding with and it’s not even that new. That’s fine! Insanity currently encodes 10 different streams off one single Pentium 4 machine. There’s really no reason not to encode multiple streams.
Let’s say we want to support mobile clients, laptops on not-so-great wifi, desktops with okay internet and desktops with really fast internet. That’s four categories – maybe five if we want to offer a very low bitrate stream for mobiles with issues.
- Mobile/Wifi/GPRS/3G – 32k, 64k
- Laptop/Wifi – 96k
- Desktop/Slow Internet – 128k, 192k
- Desktop/Fast Internet – 320k
Okay! Now we’re making life easier for our listeners. Immediately things like smartphone apps will benefit from this, as will online listeners if your site is clever enough to direct them to the right stream (or they’re clever enough to pick the right one). However, it’s not quite that simple.
Codecs and Containers
Not all clients can read all streams. AAC, MP3, AAC+, HE-AACv2, Ogg Vorbis, WMA, there’s tons of codecs out there. And while some stations feel that WMA alone is good enough, nearly nothing can read WMA except Windows Media Player. So if you want people on Mac or Linux or smartphones to be able to tune in, you’re shooting yourself in the foot. We need to provide wide coverage of codecs along with our bitrates.
MP3 and AAC are both patent-encumbered, along with AAC+ (aka aacPlus v1 or HE-AACv1) and HE-AACv2 (aka aacPlus v2) and WMA. Nonetheless, HE-AAC’s variants and AAC are fairly widely supported, particularly on smartphones and similar devices. MP3 is even more widely supported, having a few more years in the wild on its side. AAC and MP3 combined cover almost all platforms and client software including media players and browsers (without Flash, using new HTML5 support for streaming media). Ogg Vorbis is a patent-unencumbered codec and container pair which is widely used and has great support on some smartphones and major browsers, and is well-supported on Linux based platforms like internet TVs. This set of three codecs – AAC, MP3 and Ogg – is great for medium to high bitrate operations. However down at 32k and 64k, HE-AACv2 is really the only acceptable-quality codec. AAC is usable as a fallback when the enhanced version of AAC isn’t usable, but the quality isn’t great in any mainstream codec other than HE-AACv2 at those low bitrates.
So, to properly cover our bases we need to go back to our bitrates and pick our codec offerings:
- 32k, 64k – HE-AACv2, AAC
- 96k – 320k – AAC, MP3, Ogg Vorbis
At higher bitrates the difference between HE-AACv2 and AAC is minimal and the compatibility gained with simple AAC makes our life easier. So now we only need 4 streams for our lower bitrate offerings, and 9 to 12 streams for our higher bitrate connections. This is easily encoded on one or two computers with Liquidsoap, which can encode all of the mentioned formats. If you want to know more, have a look over an example Liquidsoap configuration file very similar to the one we use at Insanity.
Serving it up
Your station is now providing a whole pile of great streams tailor-made for your clients. How do they know they’re there, though? First things first – submit the streams to online directories. Apps like TuneIn host their own directories and broadcasters can submit updates for new stream URLs, and apps will select appropriate streams. There’s also tools like RadioEPG, which lets internet-enabled radios perform service following and identify streams based on media format and bitrate to select a suitable stream for the device and connection.
For a simple example of this in action, check out this page which I threw together in a bit of a rush for Insanity’s 100 Hours record breaking show attempt. Click the play now button and you’ll get audio appropriate for your system. A more complex version of that implementation has been integrated and improved on for our new website, which will be launching in the coming weeks, and has even been integrated into Radioplayer (we opted to replace the default Radioplayer Flash player entirely to support HTML5, but it’s done completely transparently, and stream selection works even with Radioplayer’s default EMP).
And just a note on bandwidth – you will, if you stream to an external server, use more bandwidth to upload multiple streams. However, in this day and age, all but the most low-end connections can more than handle the load we’re throwing at them. If your connection is really poor, you can always encode one stream locally to be streamed and then re-encoded (using Liquidsoap’s harbor functions, for instance), so long as you use a high quality codec like FLAC or high-bitrate HE-AACv2.
It’s not a particularly difficult thing to get right in this day and age, and with more stations turning to the digital domain for distribution, marketing and engagement, improving the listening experience for your station’s online listeners has to be at the forefront of any manager’s mind. While for larger stations online listenership doesn’t yet compare with FM or DAB listenership by the numbers, there’s no excuse not to do a really top-notch job of streaming when the tools are so readily available and the potential for growth is as huge as it is.
Apply the same standards and operational beliefs to online audio distribution as your organisation applies to FM/AM/DAB distribution, and you’ll make a lot of listeners very happy.