aka: How Cambridge 105 Radio’s technical team has responded to the challenge of our studios being closed by the coronavirus pandemic

The current coronavirus crisis brings a particular challenge for broadcasters. It’s at times like these that both the information, and the company, that we can provide become all the more important. This has been borne out in the notable increase in radio listening that’s been reported nationally and especially locally in recent weeks.

However, we’re still people, and although journalists and those who support them are classsed as ‘key workers’, we can’t justify keeping a shared studio space open, particularly when it’s difficult to clean technical equipment like mixing desks appropriately.

As a small community radio station with very little budget, we can’t just send presenters home with equipment that has been pre-tested and known to work, so we’ve had to get more creative. This post takes you behind-the-scenes at some of the stuff going on and I should stress it’s been a team effort from all of my colleagues in the Engineering team to keep the station on the air. This is far from just my work!

The four types of broadcast

Generally Cambridge 105 Radio operates a schedule that focuses on popular music and ‘generalist’ programming by day, moving to specialist programmes at evenings and weekends. As a general rule, many of the daytime shows are live (and have to be, as they report on current affairs and things like travel news), while we can operate pre-recorded programming for a lot of the specialist shows.

Within that split, some of our presenters have their own home studios already, while others have much less equipment, and perhaps just a laptop and microphone. We quickly identified, therefore, that there are four scenarios we needed to deal with:

• Live from a home studio
• Live without much equipment
• Recorded from a home studio
• Recorded without much equipment

The home studio scenarios

For the people with home studios (or those able to put some together at short notice), they were the easiest do deal with. Fortunately, we have a long history of doing outside broadcasts, meaning many of our computer systems are exposed outside the studio local network, and we had the option of using an IP-based feed into the studio for live programming. So, for these people we mainly had to ensure they had access to the systems they would need, issue passwords and ensure they had up-to-date copies of imaging, etc.

How do you broadcast without much equipment?

Pre-recorded programmes

For pre-recorded programmes, limited equipment hasn’t proved to be a major issue for many of our presenters, though we have needed to lend some assistance in a few areas. Our general approach is to recommend using the best microphone presenters have available with Audacity or Reaper. Non-linear editing techniques allow the spoken links to be fitted between tracks fairly efficiently, and if there’s only one presenter, this can give an acceptable result providing it is normalised. We’ve had to give a few people who wouldn’t normally pre-record their programmes access to the station’s upload system to submit the finished file, but that’s about it for programmes with a single presenter.

Where more than one presenter is involved producing a pre-recorded programme, we’ve generally been recommending Zoom to record conversations. Hidden away in the settings, even on the Free tier, is a handy option to create a different audio file for each person in the conference, which makes editing a lot easier – in particular with regards to ensuring levels are consistent.

The big challenge came with live programmes from presenters with limited equipment…

Live programmes

So how can you run a live programme when the presenter is isolating at home with just a laptop and microphone? The solution we came up with is shown diagrammatically below. A couple of us engineers set up temporary home studios, which can be used by the presenter remotely:

At the presenter’s end, there’s just a laptop with headset and a VNC client.

At the engineer’s hub, there is:

• A laptop running Cleanfeed. (This is a web-based peer-to-peer voice solution.) The presenter connects to Cleanfeed from their laptop running Chrome. The incoming audio from the presenter is routed to a mixing desk.
• A laptop running the music playout software, Rivendell, also running a VNC server, which the presenter takes control of during their programme. The copy of Rivendell has a copy of the main studio database and music library. Music played by Rivendell is sent to another input channel on the mixing desk.
• The engineer has a microphone for talkback to the presenter, which is only routed to the mixer’s aux send.
• On the mixing desk itself, the input from the presenter and the music are routed to main out. The talkback microphone and the music being played are also routed to aux send. That aux send is then sent back to Cleanfeed. This enables the presenter to hear the music being played, and also to talk to the engineer if necessary during tracks (the engineer can PFL the presenter’s feed from Cleanfeed to allow this, without affecting the broadcast).
• The main out from the mixer is sent to another laptop running either Opus Transmitter or Butt. (We prefer the Opus codec over MP3 for its low-latency qualities.) Butt now includes Opus by default in its latest version, but we’ve found that it can be unstable, so we tend to use Opus Transmitter – the older port of Butt with Opus support).
• Butt or Opus Transmitter are connected to the existing endpoint in the studio for outside broadcasts over IP.

Since the presenters have no fader control in this scenario, just the mute button in Cleanfeed, we’ve also had to produce pre-dipped versions of beds (the music used in the background of weather and travel bulletins, for example), which they can just talk over.

The only real issue we’ve found is that the presenter ends up juggling quite a lot on a potentially small laptop screen:

• emails / texts coming into the studio (presented as a secured webpage)
• travel news and other scripts
• the VNC client
• Cleanfeed in a web-browser tab, which they need to remember not to close

(Top tip: Use the ‘Time offset’ setting for the Rivendell host to account for the delay back to the studio – in our case about 3500ms. That way the presenter sees the delay already built-in on the clock over the VNC connection, and doesn’t need to do any complex back-timing calculations.)

Other things we’ve been doing

There were just a couple of systems in the studios which weren’t exposed externally, such as the studio clock (used to remind presenters of their clock hours and what’s coming next). We’ve also had to write some code to make it easier to see when IRN (Sky News Radio) is scheduled, as that previously required interpreting a crontab. Finally, we’ve now also got some code to pre-compile advert breaks into a single file, meaning that presenters don’t have to hunt for individual adverts over the VNC connection.

The results

Earlier this week, we managed to provide 14 hours of live programming, coming from six different locations across Cambridge. (This was in addition to a further four hours of pre-recorded programming.) This means we’ve been able to continue providing a valuable public service to our community, which is why we’re here.

The presenters seem pretty pleased too. Here’s Alex presenting from home…

…and here’s my home studio in use by Ian Daborn during his Saturday morning programme earlier today.

To turn this around in just a couple of weeks has been a great team effort. The only significant difference listeners will have heard is that some local news bulletins between programmes have been replaced by the national news from IRN, followed by a local news read. This is because we can use the time while IRN is on to take one feed down and bring up a different one.

Updated May 2020: Although some more programmes are now feeding to the studio directly, most of our live daytime output continues to use this system. Last month we added a 5GHz long-range wifi system to my house and that of one of the other engineers, so that we have redundant internet connections. If either of us lose internet, or it becomes unreliable, we can switch the whole system to using the other person’s network.