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.wpengine.com, 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 add your station 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, 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.
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.
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.
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.