Moving?
If you’re interested in the technical side of what we do, we’ve now moved to a dedicated site. Check it out at www.dlineradio.co.uk.
The Sound of Hospital Radio?
It’s a type of radio that’s been around for, well, literally a lifetime or so if Wikipedia’s to be believed. And the idea is simple – entertain bored patients that have to endure stretches in hospital.
The obvious approach to meeting this requirement is ward visits and spending time talking to patients. It’s amazing the difference simply talking to someone can make. Especially if no-one’s visited them for days. I’d be amazed if there’s any hospital station that would look to phase these out.
However, one question that’s always a bit controversial is “what should hospital radio sound like”? I mean beyond the obvious requests that come from touring the wards with your notepad and pen.
There’s a number of different answers to that one. The first hospital station I had any dealing with left music and programming decisions entirely down to the presenters. The only guidance we were given was that the audience is generally over 50 and on average, aged 65. It was down to us as spotty teenagers to guess what our audience would be interested in.
Though we weren’t completely clueless. Computers hadn’t quite made it into the station yet but we carried Saga on DAB as our sustaining service. It gave us a few ideas as to what we should be doing.
On a side note, what’s with hospital stations and being scared of computer technology? I’ve come across many volunteers who have actively been against the idea (even in 2014!), avoid it at all costs, blame it for the demise of the station or even are simply proud their whole show is run on well worn vinyl.
One such station like that was one I almost ended up volunteering for in recent years. Their training material insisted an old school BBC news style was the way links should be done. Everything had to be properly pronounced (no accents allowed – that’s me out) and personality was pretty much banned. Making a connection with the audience came second to announcing a request. In fact, they have a rule that a request (and the bits round it) are airtime strictly for that patient only.
If that’s the case, what’s the point in having the expensive radio setup? Running round the wards with an MP3 player will achieve the same goal.
Sadly, this is how a lot of people imagine hospital radio is. Well, throw a ton of post-war ditties into the mix and you can see why people don’t actively seek it out.
So, how should it sound? Simple – remember who your audience is? It’s bored patients with not much else going on. You want something recognisable for the ones that are really badly ill will take comfort in. Playing every obscure album track you’ve got “’cause it’s real variety innit” doesn’t meet that.
Your average audience member in 2014 grew up with the music of the 60s, 70s and 80s. That’s not to say you should completely ban anything older but your music choices should reflect this. Especially when you’re in hours of automation.
And talking about those ill patients – are you still running jingles telling people to insincerely “get well soon”? Are you still running those cheesy 70s sound jingles with badly sung messages on them? One question – why? There’s no reason hospital radio shouldn’t be running at modern production standards. If you heard that stuff on your FM dial, you wouldn’t stay tuned in would you? So why would the bored patients?
When it comes to presenters, they should be aiming to entertain. Touring the wards will make connections with the audience you just can’t do in commercial radio. Take that personal approach to air. Don’t be scared to tell stories and anecdotes (that includes stories from the wards). It’s something we push and train our presenters to do over the simple “that was, this is” request stuff. Patients still get their personal mentions but are also entertained when it’s not their turn. After all, radio is a wonderful, immediate medium that allows you to make connections and tell stories.
And talking of content, have you simply filled your daytime with any show you could get your mitts on? People don’t tune into the radio and simply listen because there’s a voice there. Carrying obscure specialist shows that you can’t bring yourself to listen to is akin to punishing your audience. That’s not to say there’s no place for specialist shows presented in an coherent and approachable fashion, but filling your schedule with all sort of junk because it’s “better than having no presenter” is very much the wrong approach. I’d imagine a straw poll of your audience will find a lot more takers for a well programmed jukebox.
On top of that, tastes don’t change when you get ill. Have you ever had a sick day from work and suddenly decided you now want to listen to some light jazz? Unless you were already into light jazz, the answer’s no. So why would patients in hospital be any different. The general public has the same tastes both in and out of hospital.
And we’re back to that music thing again. You shouldn’t just be playing any song you can get your mitts on. Listen to the classic hits stations you can get in your area. I would have recommend also checking out Smooth but they’ve changed their sound a bit recently. So, check out the Scottish Bauer AMs and ignore the “bagpipes and shortbread” stuff (unless you’re also located in Scotland…) or even Global Radio’s Gold. You should be similar in music style as these classic hits stations. However, you should also be open to more modern music. People don’t stop enjoying music as they get older but I’d stick to the big hits that aren’t too in your face.
But this is all details. Remember – hospital radio is for the same public you see day in, day out. They’re just a bit ill, don’t want to be there and thoroughly bored. Cater for that, not the clichéd hospital radio sound. You’d be surprised what it can do for your audience figures. You know, the people you’re there for.
’tis the season. Or is it?
Walk into any high street shop and you’ll be met with sleigh bells blasting out the speakers and twinkly lights hanging for everything. It’s approaching that time of the year again. Christmas and the associated complaints about it starting earlier every year.
Nine times out of ten, it’s not actually starting earlier. Well, unless you’re a well known commercial radio station in the UK who took a punt at starting the Christmas songs in mid November only to back out the next day. But that does bring us to the question when do we start playing Christmas songs? You could also ask how into it we should get.
In the commercial (and even nowadays, the community) world, the songs start appearing towards the end of November or even into the beginning of December. You’ll also be making appearances at light switch-ons and the likes. This is something I’ve always found odd for radio presenters to do. Well, unless you’re looking to disappoint your listeners with your stunning looks.
But what about when you’re a hospital radio station? The hospital does its best to get patients (your listeners and reason for existing) back home for Christmas. For those patients, you can do a build up towards the big day and make a big deal about it. But what about the long term patients? Those that will be enjoying the hospital’s best attempt at turkey with all the trimmings?
The answer there is that you don’t really want to be making a big deal about it. They’re resigned to the idea of spending the big day away from home.
My solution to the conundrum has been to edge more towards the patients that aren’t going home when programming the station. We have had special Christmas programs on the day for years (even before I joined). However, you won’t hear a word about Christmas on the station after the 25th. It’s all done and dusted at that point.
As for the music side of things, we strictly ban any Christmas songs until 1st December unless by patient request. I’ve yet to see a request break this rule. Not really surprising with the older audience that hospital radio attracts.
Even once we start playing the songs, we make them rare treats. We start at one song roughly every four hours. This slowly ramps up to one an hour on the week before the big day. Only once we’re at full pelt do the cheesy Christmas rehashes of our jingles come out, complete with sleigh bells. Thankfully they only make appearances directly into or out of Christmas songs.
While you might have guessed I’ve been compared to Scrooge in the past, this approach seems to work well and makes sense to most people I explain it to. It’ll no doubt get some complaints again this year from some of the volunteers who want to go all-out Christmas and bang sleigh bells out over every song. However, I think we’re striking the right balance. What do you think?
IRN Switching – The Weird Way
It’s approaching the top of the hour. Your jock has padded out their last link as much as possible to hit the news on time. The jingle fires and IRN goes out on time. It sounds neat when it’s done correctly. However, doing it in automation is a bit of a pain.
The problem is how to route the IRN feed to air for the two minutes every hour. I’ve seen all sort of approaches ranging from flying faders and automated routing to piping it through a soundcard on a timer. The later of these was supposed to be the approach when I was a presenter on a small commercial radio station. Except… the weekend automation hadn’t been setup correctly and I had to resort to taking it manually. That’s the joys of being in the now defunct station’s opening line-up.
However, none of these approaches quite match what we’re working with at one volunteer station. The station audio router is a 12-way Alice OS switch. Yup, clunking great physical buttons with no automated control. Well, unless we built a robot of some sort to push them for us.
On top of that, we only want the feed to go out during our automated output. It’s that or keep interrupting live sport (sports teams don’t take well to this and actually question why we bother with news at all).
For that reason, we’re doing a playout controlled mix. Now we would do this with soundcards and even toyed with the idea timeshifting to allow the song to end before going to the bulletin. However, as the previous post alluded to, it’s been a right pain getting the soundcards to work.
So, out with the software and in with the Raspberry Pi and a modified Alice Mixpak. We’ve actually cracked out a soldering iron and put a four pole relay across the first pair of inputs on the Mixpak. With a transistor in the circuit and tapping off the +15V line in the Mixpak, we can switch the input on and off with a little bit of voltage.
If you can’t picture what we’re doing here, check out http://www.susa.net/wordpress/2012/06/raspberry-pi-relay-using-gpio/. It’s got the original diagrams we worked from.
That said, I would show you the guts of this but it’s not very neat. Well, that and it’s now live and I forgot to take a photo. On top of that, my soldering skills are pretty poor.
What I can tell you about though, is wiring and configuring the Pi. On the Pi we connect GPIO 17 to our transistor and join the grounds together. However, a word of warning. The Pi doesn’t have much in the way of circuit protection on the GPIOs. Do it wrong and you could fry it.
Despite that dire warning, if you’ve got this far, you’re ready for the software side of things. We start by installing Raspbian on the Pi. So long as you set a sensible password for the pi user and enable SSH, it should be enough to get us going.
We now want to create a file called /home/pi/gpio.pl with the following contents:
#!/usr/bin/perl
use IO::Socket;
# Script-wide variables
$port = 5050;
$gpio = 17;
$MAX_LENGTH = 1024;
# Setup the basics
system("echo \"${gpio}\" > /sys/class/gpio/export");
system("echo \"out\" > /sys/class/gpio/gpio17/direction");
# Setup the UDP socket and wait
$server = IO::Socket::INET->new(LocalPort=>$port, Proto=>"udp") or die "Failed to create a socket on port $port. The error $@";
while ($server->recv($action, $MAX_LENGTH)) {
# Check the input
if (index($action, 'ON') != -1) {
system("echo \"1\" > /sys/class/gpio/gpio${gpio}/value");
print "IRN ON\n"
} elsif (index($action, 'OFF') != -1) {
system("echo \"0\" > /sys/class/gpio/gpio${gpio}/value");
print "IRN OFF\n"
}
}
The script doesn’t do anything too clever. It prepare GPIO 17 to be an output pin then toggles it as UDP packets come in on port 5050.
Specifically, we’re looking for the values “on” or “off” in the packet before we toggle. These packets in turn are generated by Rivendell as and when we need to switch. The benefit of doing it this way (as opposed to using timers) is the ability to be flexible with things like the Queen’s speech.
The final step is to configure the script to launch on boot. We do that by adding the following to the /etc/rc.local file:
/home/pi/gpio.pl &
Playing Nice with the Delta 66 and ALSA
We use Rivendell as a playout system for a little radio station I help look after the technical side of. It’s a neat little system and usually quite simple to get going. However, the studios at this station are tiny and definitely not designed to work in the computer world. This meant multiple monitors and therefore PCs would be impractical.
So, that left us with a problem. We’ve got a Delta 66 we effectively want to split into two soundcards. The first half will be purely for playout. The second half for hotkeys, audio editing and general web browsing. Yes, I know we shouldn’t have web browsing and playout on the same box but it’s what we’re stuck with.
Now you think this would be a fairly simple exercise. Erm… it isn’t. ALSA’s card sharing plugins, DMIX and DSNOOP, aren’t well documented. Neither is the routing for multi-channel soundcards. It’s not a surprise though when you consider how often you’d do this outside of specialist applications like radio studios (somewhere near never).
So, here’s the config file (to be stored as /etc/asound.conf) I managed to come up with after a lot of trial and error. It doesn’t work 100% (the record part is a bit broken) but it’s what a lot of staring at half-written documents and examples results in.
# DMIX plus DSNOOP
pcm.delta66dmix {
type dmix
ipc_key 1023
ipc_perm 0666
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
channels 4
}
bindings {
0 0
1 1
2 2
3 3
}
}
pcm.rd0dmix {
type route
slave {
pcm "delta66dmix"
channels 4
}
ttable.0.0 1
ttable.1.1 1
}
pcm.rd1dmix {
type route
slave {
pcm "delta66dmix"
channels 4
}
ttable.0.2 1
ttable.1.3 1
}
pcm.delta66dsnoop {
type dsnoop
ipc_key 1021
ipc_perm 0666
slave {
pcm "hw:0,0"
channels 4
period_size 1024
buffer_size 4096
rate 44100
periods 0
period_time 0
}
bindings {
0 0
1 1
2 2
3 3
}
}
pcm.rd0dsnoop {
type route
slave {
pcm "delta66dsnoop"
channels 4
}
ttable.0.0 1
ttable.1.1 1
}
pcm.rd1dsnoop {
type route
slave {
pcm "delta66dnoop"
channels 4
}
ttable.0.2 1
ttable.1.3 1
}
pcm.rd0 {
type asym
playback.pcm "rd0dmix"
capture.pcm "delta66dsnoop"
}
pcm.rd1 {
type asym
playback.pcm "rd1dmix"
capture.pcm "delta66dsnoop"
}
ctl.rd0 {
type hw
card 0
}
ctl.rd1 {
type hw
card 0
}
# Set the default card
pcm.!default {
type plug
slave.pcm "rd1"
}
ctl.!default {
type hw
card 0
}
Looks a bit horrific. And to be fair – it is. So, let’s break it down a bit as it’s far more easier to digest. And where better to start than the first bit:
pcm.delta66dmix {
type dmix
ipc_key 1023
ipc_perm 0666
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
channels 4
}
bindings {
0 0
1 1
2 2
3 3
}
}
This part sets up the sharing on our Delta 66 for playback using the ALSA DMIX plugin. The “delta66dmix” part is just the name we’ll use to refer to it. However, the next bit is a little complicated. Every virtual “device” we setup on this system will need its own unique IPC key. On top of that, we need to be careful about permissions. By default, ALSA will configure all this as the root user (unless you plop the config into a user’s asoundrc file). The ipc_perm value of 0666 tells the system to share the device with everyone complete with read/write access.
The slave section is the settings for the soundcard itself. We want to run it at 44,100 Hz with four channels. Oh, and because it’s the first physical soundcard, it’s identified as hw:0,0.
The bindings bit is literally mapping outputs 1-4 on the virtual shared device to outputs 1-4 on the physical device. However, programmers (computer, not radio) count from zero. Thus the 0-3 rather than 1-4.
pcm.rd0dmix {
type route
slave {
pcm "delta66dmix"
channels 4
}
ttable.0.0 1
ttable.1.1 1
}
The DMIX setup in the first part was to ensure we could share the soundcard. We now want to split it into two virtual cards. This is where the “route” plugin for ALSA comes in. Here we’re connecting the first two channels of the Delta 66 to our first virtual through the ttable commands. You can think of these as routing commands.
One thing worth noting is that while we’re only hooking up two of the channels, we need to declare the soundcard as having all four channels. Otherwise we can’t route all the channels.
pcm.rd1dmix {
type route
slave {
pcm "delta66dmix"
channels 4
}
ttable.0.2 1
ttable.1.3 1
}
Look familiar? It’s hooking up our second virtual soundcard to the third and forth channels of the real soundcard. Thus the 0.2 and 1.3 entries.
That said, all we’ve got so far is two virtual devices for output only. We need to look at input.
pcm.delta66dsnoop {
type dsnoop
ipc_key 1021
ipc_perm 0666
slave {
pcm "hw:0,0"
channels 4
period_size 1024
buffer_size 4096
rate 44100
periods 0
period_time 0
}
bindings {
0 0
1 1
2 2
3 3
}
}
It looks a lot like the DMIX configuration and a lot of the concepts match. However, we’re using the ALSA DSNOOP plugin to share the recording device.
pcm.rd0dsnoop {
type route
slave {
pcm "delta66dsnoop"
channels 4
}
ttable.0.0 1
ttable.1.1 1
}
pcm.rd1dsnoop {
type route
slave {
pcm "delta66dnoop"
channels 4
}
ttable.0.2 1
ttable.1.3 1
}
Hmm… this is getting a little repetitive. We’re using the ALSA route plugin again. However, this time we’re creating two virtual recording devices.
And that’s great. But what we really want is two virtual devices that do playback and recording. That’s where the ALSA asym plugin comes in.
pcm.rd0 {
type asym
playback.pcm "rd0dmix"
capture.pcm "delta66dsnoop"
}
pcm.rd1 {
type asym
playback.pcm "rd1dmix"
capture.pcm "delta66dsnoop"
}
Literally all we’ve done here is create two virtual ALSA devices called rd0 and rd1. These tie together our recording and playback devices.
Well, that’s the theory. I couldn’t actually get the DSNOOP bits to play nicely with routing. For that reason, we share the whole soundcard across the two virtual devices for recording.
ctl.rd0 {
type hw
card 0
}
ctl.rd1 {
type hw
card 0
}
These bits are purely in the configuration for the playout system Rivendell. It gives the virtual cards a control/mixer interface… that points to the control/mixer interface for the real card. Turns out you can’t create a control/mixer interface for the virtual devices. Well, I couldn’t find a way.
# Set the default card
pcm.!default {
type plug
slave.pcm "rd1"
}
ctl.!default {
type hw
card 0
}
This final bit literally does what it says on the tin. We set the default soundcard to be our second virtual device. We do this because in a studio environment you want the main playout system on the first card and everything else on the second.
It’s not an ideal setup for a studio but it works… sort of. Hopefully this will help you with your ALSA configurations.
Soundcards – The Linux Way
It’s not often you’ll catch me singing the praises of Windows but when it comes to sound cards it’s got to be a winner. Every professional, balanced sound interface I’ve come across comes with drivers for the OS. But what about the Open Source Linux world?
Well, you might call looking at Linux a waste of time in the professional audio world. However, with playout systems like Rivendell capable of powering some of the smaller stations (community or small scale commercial) and editing software like Ardour or Audacity (just as capable as Audition in my eyes and at the right price), it’s possible to run your station in the Open Source world.
However, when it comes to hardware things are still a bit hit or miss. Your off the shelf 99p AC97 special will probably work A-OK. The professional balanced card you’ve had for years – maybe not. It’s often cited that Audio Science cards will work very well with the right drivers. I can’t comment on this as they’re not hugely popular in the UK and I’ve never come across in the wild I can test with.
On the other hand, the M-Audio cards (Delta 66/1010) seem to just work out the box. In fact, it’s the Delta 1010 running under Linux that RadioMonitor are often seen using on their logging boxes.
As for other cards, Digigram options are a bit hit or miss. Some will work if you get the right firmware and loaders installed. Others have no Linux drivers whatsoever. Oh, and it’s worth pointing out they don’t play nice with Rivendell (any VX222 cards I’ve played with throw some nasty errors when your do).
One of the more exotic options I’ve tried to get working was the Lynx 2. It required a special distribution of OSS (an older audio API for Linux) and while it would pump audio, didn’t play too nice with Rivendell under ALSA.
That said, if you do find a soundcard that plays nice and has drivers, you’ve got yet another issue with audio under Linux – what API/audio engine do you use? ALSA seems to be the default and is what applications like Rivendell will use by default. However, by default ALSA will not share a soundcard between applications. Oh, and if you do want to enable it, be prepared to mess around with config files (I’ll be talking about this in a later post – splitting a Delta 66 in two and sharing between multiple applications including Rivendell playout).
Another option is JACK. It’s an amazingly flexible system that allows you to plug applications and sound cards into each other. You could (in theory) have your playout, processing and distribution all on one box with this system. Heck, throw in some open source DAB TX software (plus associated RF hardware) and you could have your TX system in that box as well. Catch is that JACK really needs real-time priority and can be a bit fiddly to set up with hardware.
You can also use OSS for audio. While some systems like Digiplay will need it, it is getting on a bit now and not directly supported in much software. The trick if you’re using systems like this is to emulate OSS using ALSA or JACK (with the right software).
So, the upshot is it can be fairly plug-and-play in the Linux world but it can be a real hit or miss exercise (with a lot of misses) at other times. Shame really as I’ve worked with Linux for years in broadcast but it’s never come up to the same ease of use level as Windows when it comes to audio.
STLs and Raspberry Pi(e)s
So, you’ve got this neat little radio station in town and a transmitter on top of a windy hill. Sounds awesome but have you ever considered how you get your Sony Award winning* programming out there? Well, the answer is a Studio Transmitter Link (STL).
Now, on your big commerical radio stations, this link tends to be a dedicated digital circuit like Kilostream. Sounds great but any engineer with more than 10 seconds experience on the job will tell you things break. Oh, and things like squirrels and rain may knock things out temporarily. So, you use something like ISDN as backup (and you thought it went the way of the dodo when ADSL became popular). Or, if you’re a bit stuffed at that point, you can always rebroadcast another transmitter (risky if you’re enjoying atmospherics or have some nutjob hell bent on delivering their view on the world).
Even then you’ve got a CD with “bangin’ choons” from about 10 years ago ready to play at the transmitter site if things go wrong. But what if you can’t afford this sort of stuff. Well, you have to get creative. Many community stations are turning to point-to-point WiFi links. Low cost and occasionally suffer from rain fade but not bad for the cost.
There’s also FM links, ADSL lines and even older circuits like Musicline One or balanced twisted pair. And that’s what one station I’m helping has been using for a very long time now. In fact, the line dates back so far that it used to be patched in at the exchange for OBs!
However, it is one of the few of these lines that still existed between two exchanges. And this proved a bit of a problem when the line suddenly went down with no warning. Turns out there was some work at one of the exchanges to remove old bits of kit. Guess who’s line was among that kit. Now, we did get a hasty EPS replacement thrown in between the two exchanges but for the price this station’s being charged and because it’s likely to happen again, we’re looking at new options.
And that’s where the Raspberry Pi comes in. This station is closed loop so has no real transmitter to worry about and does not derive revenue from on-air content. Upshot is we can be fallible (to an extent).
This all means we’re now ordering an ADSL line for the remote end and sticking a Raspberry Pi in to pick up a web stream. Admittedly the Barix Extreamer is very nice but a bit costly for our purposes. On top of that, we can configure the Pi to have some more complex fallback and alerting options with the LiquidSoap software. And that’s what I’m going to talk you through – setting up a Pi as a remote end codec.
So, without further ado:
- Acquire a Raspberry Pi. Purchasing one from CPC/Farnell is much more appreciated than nicking one from your colleague.
- Install Raspbian. It’s not that complicated and there’s a lot of guides out there. However, when you get to the installer wizard bit, we want as little RAM as possible for the GPU (I don’t know of many codecs that need 3D graphics with fancy shaders), to turn off boot to desktop, to set a sensible password for the pi account and to enable SSH.
- Fire up your Pi and install LiquidSoap. The command is literally
apt-get install liquidsoap
- If you’re pulling an MP3 stream or planning on using MP3 backup audio, you’ll need to install some of the LiquidSoap plugins.
- Create a file called /home/pi/stl.liq and bung in the following contents:
# STL Liquidsoap Config # Logging set("log.file.path", "/home/pi/log/liquidsoap.log") # Setup our sources main_url = "http://yourserver:8000/stream_name" emergency_audio = "/home/pi/emg.wav" # Now our e-mail alert routine def silenceHandler() system("/home/pi/mailsend.pl"); end # Our main source is streaming with silence detection radio_stream = input.http(main_url) radio_stream = on_blank(silenceHandler, radio_stream) # Fall back to an MP3 file # Also worth noting, if we get this far, we ought to tell someone (if we can) emg_file = single(emergency_audio) radio_stream = fallback(track_sensitive = false, [radio_stream, emg_file]) # Finally, pump it out the soundcard output.alsa(radio_stream) - Add a line to /etc/rc.local before the exit command with the following:
sudo -u pi liquidsoap /home/pi/stl.liq &
That will start LiquidSoap on boot – awsome. - Copy a backup audio file to the Pi. On this system we called it emg.wav. You can call it whatever you want but you will need to change the above script.
- Run alsamixer and bump the levels all the way up (for most installs).
- Reboot and you’ll have a little codec. Try pulling the network lead out and seeing what happens.
So, that’s is all configured and running but what does it do. Well, by default it will pull a web stream from the URL of your choice and play it out of the sound card. If it goes silent, it runs a script called mailsend.pl. This is a shifty little script that we have to e-mail us when things go silent.
However, if the stream fails completely, we fall back to playing the emg.wav file on loop. Sounds good but it’s worth remembering that it will resume the backup file from wherever it stopped last on every subsequent failure. While that might sound odd to the ear, you don’t end up hearing “She Wolf” every three minutes when the ADSL line flaps.
*May not actually be Sony Award winning.
Dead Air 
Recent Comments