Guest Post: "The technical side of a radio station" by Arran Hodges

When we had an idea to start a radio station- we didn’t really know where to start. There is so much work that goes into it- a lot on both the technical side and on the actual station output side too! I’ve done quite a bit of the setting up of the technology so I’ll go through some of the things that I had to think about before deploying networks and technology to keep a radio station online 24/7.

We had so many meetings back and forth with the brilliant guys over at Broadcast Radio. They produce a piece of software called Myriad. This is by far the biggest technical challenge that I have had to think around- since it’s not designed for our specific use. The whole application runs off of either local files or SMB shares and a Microsoft SQL server. There are four different instances that we had to plan around. Two of these instances would be in the same building as the server- however the rest would have had to have gone through a VPN connection in order to achieve remote access.

So- firstly.. how do we connect the multiple sites together? As a small start up the budget for anything technical is extremely small. Upon joining a group which discusses all things to do with the software that we used there was a suggestion made for people who use the Remote Voice Tracking client to use ZeroTier VPN for security and other reasons. Upon inspection- this particular client combines the capabilities of a VPN and a software defined network. ZeroTier is also an open source application that provides peer-to-peer connections- meaning that the connection doesn’t need to pass through any kinds of servers and as a result the latency seems to be brilliant. We took the advice that was in the support group and adapted the model of the use to be for our larger network that ran playout installs and SMB shares + connect together our SQL server to the different networks to give up-to-date information regarding playout and also have the ability to have 2-way-syncing. This worked really well for us.

It’s crucial that we had playout installed physically rather than the cloud because of this exact reason- I don’t believe we could have achieved what we have done without having it physically stored. The drawback of having this physically installed is that it runs off of a home network that can get congested at times (meaning slower loading times) and doesn’t have a suitable SLA agreed with the provider- therefore susceptible to drop outs in the transmission chain. We’ll talk about the ways to prevent the station going off air at this point later on. It’s worth noting that we have imported as much as we can infrastructure wise to FyfeWeb– a brilliant service provider. You should check them out.

Let’s talk about the transmission chain altogether. There are lots of moving parts within this;

Everything runs from Icecast within this chain. Since a physical audio switcher isn’t possible- this is the next best thing. The switching is done via fallback mounts on the raw feed of audio that’s being sent. Remote Contribution could be any of 3 studios- when they are live, they get broadcasted out to the listener via the two Icecast relays. As you can see from the diagram above- this goes through about 3 servers and 7 mountpoints. What’s not being seen here, though, is the transcoding that’s happening behind the scenes to provide lower bitrate mountpoints in formats like AAC or MP3. The audio switching on the playout system side is handled by Myriad’s built in smart log transfer.

Speaking of Icecast- it’s vital that you provide all of your audio via SSL now. Chrome 80 that was released earlier on this year had a security upgrade that meant that HTTP media requests would automatically get upgraded to the secure form, HTTPS. If HTTPS is unavailable- the request will fail. This was an issue for many stations around the globe that didn’t really know about this feature update- listeners weren’t actually able to tune in online to a lot of commercial stations here in the UK- which wasn’t a desired outcome. You can view more about Mixed Messages on chrome here.

So- it was important that we had a version of Icecast that supported SSL. There were two main options- Icecast-KH or a modified version of Icecast that Xiph provides with support for SSL. Since I didn’t have much knowledge of streaming solutions back then I decided to opt for the pre-compiled Xiph version of Icecast. Adding SSL is actually more simple to do than I imagined with Icecast- I make use of the LetsEncrypt certbot which gives you a free SSL certificate. Since we have 2 relays to add SSL to that are in a DNS round robin- it’s always interesting to see which one resolves first. This also means that we have to keep a close eye on expiry dates- as we can’t automatically renew both at the same time. There is a configuration I have found for it but I’m not particularly interested at this point in pursuing it.

Going off air in the case of a network dropout was a significant concern for me personally as it’s placed in a home environment. I’m not worried about the physical equipment- just the network that it ran on so I made sure that there were contingencies in place in the case of a network dropout. On both relays- there is a separate “backup” stream that is with a completely different provider that will automatically be fallen back on if connectivity goes boom. This has saved us in so many ways imaginable- from routine system maintenance to full on disasters this has always been a part of our contingency plan that every single station should have. This backup stream runs from open source software, namely AzuraCast. Additionally- AzuraCast provides all of the transcoded streams for the relays to play at lower bitrates too. It’s a brilliant piece of kit for you to use. Check them out here.

Also- since there’s no silence detection along the chain of transmission we have placed a silence detector that listens to the feed of both streams (studio 1 and remote contribution) and run PiraCZ silence detection software in order to be notified when something may go down. This is placed on a server in a datacenter so emails can still be sent if the network connection has stopped working in the main location.

The whole prospect of both server and playout upgrades are daunting for anyone who works with servers. It’s extremely time consuming but a small task compared to some of the security flaws that have been discovered with certain versions of Windows. Firstly- we need to install the specific Windows & Myriad version we want to upgrade to on a machine that doesn’t power any on air output just in case the update messes up drivers for audio cards and things. Once it’s been verified that everything works- the playout is transferred to a remote location that caches the audio that’s in the playout system and the next 50 or so media items so that the station can carry on running from the outside broadcast mount. Then both the server and playout PCs are upgraded and maintenance is performed on them- and then everything should be able to be transferred back to our “automation” PC.

We haven’t even gone into the depths of audio routing and how presenters can go live using AOIP from across the UK.. but I think that’s enough of telling our secrets for one day!

Once everything is put together- you get a radio station that is online 24/7.