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.

Moving Parts

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.

Most importantly though is the station website. At the very least you can offer a list of streams, but why stop there? It’s fairly trivial to write some Javascript which performs a quick and relatively accurate bandwidth test between your client and the server, and then uses the knowledge of the bitrate combined with knowledge of what the browser can play (provided by the Soundmanager2 library) to automatically pick a stream. This lets us support, with no more than one mouse click for a listener (to click ‘Play Now’), fully automatic best-quality streaming with no listener intervention. As it should be – making things easier for everyone.

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.

Summing up

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.

If you’ve got a smartphone, or a modern DAB/FM radio, chances are it can connect to the internet on 3G or wifi. This lets your smartphone also check your emails, and your modern radio listen to internet radio streams. But what it doesn’t let you do is find out more about the station you’re listening to. At least, until now. (Read that in a dramatic voice and let the tension sink in a little. Done? Then let us proceed!)

RadioDNS is the link that lets radios tuned into a DAB or FM (RDS-encoded) service figure out what the website is for finding out more about that service. This takes the form of applications, like RadioVIS, RadioEPG or RadioTAG. Of these, only RadioVIS is standardised at present, though RadioEPG and RadioTAG are progressing well. The way it works is really simple – the parameters that make up an FM RDS or DAB transmission (country code, station identifier, frequency etc) form a rather odd sort of reverse DNS request to radiodns.org, which is operated by the RadioDNS group. You tell them where to send these incoming requests (your station’s DNS servers), then set up some records containing information on how to access any applications you’ve got running (in SRV records).

RadioVIS is a pretty interesting thing because it’s a really neat way to add content and information to the listening experience on any receiver. Essentially it entails telling your clients to grab a specified image from the internet and display it along with some text you can specify. The way you communicate these updates is with Stomp, a very simple protocol. The image and text can be whatever you like, which really lends us some flexibility, particularly since the distribution is done by pushing to clients, meaning that the content can be temporally synchronized with what you’re playing on air. New show or song? Show something about it! Nothing changed lately? Show an advert or the upcoming schedule.

So how do we implement this? Well, RadioDNS is really easy – you just set up some DNS records and have a chat with the fine people at RadioDNS. This lets receivers find you, and once you’ve put the right SRV record in your DNS, receivers can find your RadioVIS implementation. Now all we need is a Stomp broker, something to generate our content, and something to send our content updates to the broker and thus our clients. Brokers like Apache ActiveMQ (which is a horrible pain to get working, but works well once it’s running), Apache Apollo or Rubystomp are available, and while some setup is required, you only need to do it once, and example configurations are out there.

An example slide showing the upcoming schedule

Now we’ve got our broker, we need to actually generate our content. There’s loads of ways to do this, in theory. One approach is to just use manually created slides – make slides for all your content, link up the image files to your playout schedule, and off you go, or just have a static content rotation. This isn’t going to scale well, though, and the best approach is to procedurally generate them when needed. For this task I turned to SVG and the Inkscape project, plus ImageMagick. Our new website at Insanity Radio 103.2 is a Ruby on Rails application and has our schedule built into it, so I created a Ruby gem which takes SVG templates, background images, and data, then combines them and renders them to be sent to receivers.

The SVG templates have either all the images etc embedded into them or a transparent background (with embedded images overlaid). Textual content is defined as text fields like “$$TITLE$$” in the SVGs. This means we can pull the SVG template into Ruby, quickly substitute out those strings for our actual content, and write it out again. All we need to do then is render the SVG and, if needed, composite it over a background image. This gets us really nicely rendered text in whatever format we like, with loads of flexibility. We can also include arbitrary images in the SVG templates using this method by specifying images in the same way as text fields.

An example slide showing branding with show information

There’s other ways to go about doing this, of course, but almost all of the systems out there already do something along these lines, and this is certainly the easiest and most simple to expand method I’ve come up with. All we need now is to send out these slides, along with any textual info we want. I have the slides generate the text to display alongside them, but you might want to split it up. Either way, all we do to publish these is to send a message to the appropriate Stomp topic with “SHOW http://imageurl.png” or “TEXT Stuff to say.” The topic is constructed as specified in the RadioVIS spec – for our UK FM station, it’s /topic/fm/<ECC>/<PI>/<FREQ>/<TYPE>. So ours maps to /topic/fm/ce1/c08f/10320/(image|text). DAB has a different format, of course.

But wait – what we now have is a system that lets hybrid radio receivers (ie FM/DAB+internet) display cool content. The PURE Sensia is one of the only such receivers at present. It’s not exactly widespread. Undoubtedly we’ll see more receivers on the market. But wouldn’t it be neat if we could bring this to the internet listeners? Yes it would! Particularly for student stations, where very few people have high-end radios, this is a great plus.

I mentioned WebSockets a little earlier, and this is what Apache Apollo provides us. WebSockets are a non-HTTP way of communicating between a server and your browser and they’re great for doing push communications to clients. They’re fairly new, so only supported by fairly recent versions of Firefox (11+), IE (11+), Chrome (13+) and Opera. But that’s actually quite a decent percentage of users these days. We can also fall back on AJAX calls to load some known images in a static rotation if we want to support those users. A non-fallback example of the Javascript is demonstrated here, using the Stomp-Websockets javascript library and jQuery.

Another example slide showing a show's picture and information

So at this point we can include time-synchronized images and text in both hybrid radio receivers and embedded in your online player (such as Radioplayer). This has the huge benefit of massively improving the value of the RadioVIS infrastructure for primarily online stations, and making implementing, maintaining and developing content for the platform much more attractive to station staff. Particularly in a system like ours where presenters are encouraged to look after their show information, picture and tagline, it’s a great reward for presenters to see their content come up next to the stream.

RadioVIS and RadioDNS is really great, and the RadioEPG and RadioTAG specifications are also interesting systems that are worth keeping your eye on – I’ve implemented a basic RadioEPG PI/XSI API set in the new content management system I’m developing with Insanity, and I’m going to be watching the finalisation of that specification with interest, along with RadioTAG. There’s not a lot of practical implementation details being shared around at the moment, sadly, but hopefully things will change as this all becomes more widespread.

This time I’m going to be talking about how to properly power a transmission system, and how best to deal with uninterruptable power supplies (UPSes) in terms of cabling, monitoring and long-term care.

FM systems are much easier to worry about power and grounding for than AM systems, at least on smaller installations. There’s fewer moving parts (so to speak), and so long as your equipment is properly earthed, there’s no real issue with grounding (as opposed to AM where you get to deal with grounding mats and so on at your mast). The main issue then is that of power distribution and redundancy.

Most community stations aren’t going to have the budget or resources to deal with a truly redundant system – that is, one which can run without any utility power for a period in excess of an hour. On the other hand, outages that are likely to take your utility power away for more than an hour are, at most stations, quite rare. Such a highly redundant system requires a generator, a means for switching to and from the utility power and the generator, and if this needs to run without human intervention (as it ideally should), you also need all of this to be automated (typically with an automatic transfer switch). This lot gets quite expensive rapidly, and there’s running costs for a generator (fuel doesn’t last forever, so even if you don’t use your generator for 12 months you need to empty and refill the tank, service it, and so on).

The cheaper option is to spring for an uninterruptable power supply, or UPS. There’s plenty of vendors out there but APC dominates the field, and with good reason – they’re reliable bits of kit and I’ve personally used them for everything I’ve needed a UPS for. They’re also very easy to pick up second-hand on eBay, which makes them very favourable from a cost perspective. I’m typing this on a computer which is plugged into my room’s power distribution system, which is fed from an APC Smart-UPS 1500VA, which I originally picked up because of a very unreliable 16A ring breaker in my first student digs. That cost the princely sum of £170 with new batteries fitted – well within any station’s budget.

There are a few types of UPS, but mostly at the sort of level community radio operates at you can break the considerations down to ‘standby’ UPSes, ‘line interactive’ UPSes and ‘online’ or ‘double conversion’ UPSes.

Standby UPSes are the dumbest sort of budget, entry-level UPS, and they simply check for voltage within a certain range on the utility feed. If that voltage falls outside a certain range, the batteries take over. They’re cheap, work fairly well, but don’t handle undervoltage/overvoltage situations very well as the system has to switch to batteries to continue running.

Line interactive UPSes are slightly cleverer, and contain a multitap transformer to let utility power keep powering systems even in under/overvolt situations in addition to having batteries for total outages or extreme under/overvolt scenarios. These are the most common sort of UPSes found in small to medium size deployments, and don’t cost a lot more than standby UPSes.

Finally we have the online or double conversion type of UPS – these are the best available type, as they use (as the name implies) online conversion to effectively constantly power the output from a rectifier, meaning that the resulting power feed is clean, free of noise and harmonics, and effectively perfectly stable. In the event of power under/over voltage they can use line interactive style autotransformers to correct until batteries are required.

For RF transmission installations the online UPS is absolutely the right thing to have, mostly because they effectively ensure your power will always be clean and free of anything nasty that could affect your gear, but also because they typically have longer battery lives (due to being able to avoid switching to batteries more regularly) and are more easily expandable with add-on battery packs because of their design.

The other major thing we have to be concerned about in a broadcast environment is monitoring. UPSes are totally useless if they cannot be monitored, as batteries have a limited lifespan, and power loss situations should always be reported and followed up on, or at the least logged for post-mortems. If you’ve got a PC in the rack with the UPS, then this is trivial with most systems – all modern APC UPSes feature a USB or serial port to connect them to a PC, and SNMP cards are available as an upgrade for most (but not all) models, allowing you to talk to the UPS via the network.

For Linux, the excellent program apcupsd is available, which can be used to connect to, query and control an APC UPS via serial or USB. This can then be queried from your monitoring system (we use Nagios, but anything with a plugin architecture should be able to make use of it, like Munin) to ensure proper operation.

Keeping logs of device behaviour and self-tests (which you should have set up to run every month) is important, and must be done locally to the machine – networks, particularly large ones, tend not to be fully power-maintained, and you shouldn’t rely on them even if they are to be able to work out what went wrong after the event. apcupsd can write a nice event log to disk for you, and can be queried via a friendly web interface, making management and post-mortems quite straightforward.

Finally, with computers at the TX site, shutting down those machines before they run out of power is a good last-ditch precaution. If you’ve got a minute of battery power left, abandon all hope and shut down – but make sure that on power restoration, the machine comes back up automatically, or you’ll end up not getting your TX back when you get power back. Which is bad, obviously. Again, apcupsd can handle automatic shutdown for you.

The only other thing that you need to think about in your system is ground loops and distribution. A solid approach is to have the UPS plumbed directly into utility power, but if you do have a power strip in your transmission rack, isolate it with some plastic washers to stop it from being in contact electrically with the rack itself. The UPS power distribution unit (PDU) can then be grounded to the rack along with the other equipment. Make sure that your PDUs have switch covers to prevent accidental shut-downs.

Once you’ve installed everything and tested it, a runtime calibration test will give you an idea of how long your batteries last under expected use. Don’t forget to label all your cables on both ends, and to document what cable is which device, particularly with concealed power cable routing (behind equipment). Once you’ve done this, do a complete power down test – remove utility power, and time how long it takes for the system to fail, ensuring that your PC shuts itself down just before failure. Then restore power and ensure everything comes back up. If this doesn’t happen, figure out why and resolve the issue until you can pass this test, and you’ll be well-powered forever.

Well, almost forever. Most batteries in UPSes should be replaced every 5 years, but defer to the manufacturer for exact replacement schedules. This is an important task and can often be forgotten until one day the UPS only runs for 5 minutes instead of 30 minutes. Monthly maintainence procedures should include a check of the last replacement date in the UPS firmware, and you should update this date in the firmware after doing a replacement so you can keep track. This method makes it very hard to forget, since you’re regularly checking it.

And there you have it – how to keep your station on-air through brownouts, surges, powercuts and more. Given how cheap UPSes are and how beneficial they can be to the lifespan of equipment behind them (particularly online UPSes), it’s a no-brainer to have one at your TX site.