RadioDNS and RadioVIS – Getting Started

Okay, this is gonna be a weighty one. But it’s an interesting one, for me at least, and I hope for you too.

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.

7 thoughts on “RadioDNS and RadioVIS – Getting Started”

  1. Great summary and good to see you using slide generation through rendering – more people are using this now, and its something that going to fit in well with the new functionality in the 1.1 RadioVIS specification (i.e. content negotiation on slide sizings).

    I’d certainly urge you to look again at ActiveMQ – its not so hard once you beat it into submission. I’ve seen configurations fall over daily with 100s of concurrent users and I’ve also seen configurations run for months and months with 1000s of concurrent users. They key appears to lie with setting the relevant limits on resource usage – thats something that people on the RadioVIS project would be happy to help you with. ActiveMQ also comes with the correct setup for authentication which is essential when using in production.

    RadioEPG spec to my mind is 99% done, and is going to be followed up with a set of HOWTO documents explaining how it can be best used in practical examples. Be great to get some input from the Student Radio community into what they could get from it, and how a RadioEPG service could be organised for different groups.

  2. RadioEPG reads very much as a completed spec – it’s tricky trying to implement as an FM station (since the underlying SI document is designed for DAB), and we’re still in the early days of Radioplayer implementation but that seems to want PI/SI files in some vauge and undocumented way. It’d be great to see widespread adoption of RadioEPG, though, and support for it in player applications, particularly on mobile devices (alongside RadioVIS). But we do still have a (probably fairly questionable) implementation – I look forward to having software able to make use of it!

    ActiveMQ is a great bit of software when properly configured – I’ve historically written applications around it catering for hundreds of messages a second with hundreds of users subscribed to feeds, and it is great once you’ve configured it. However, with WebSocket and Stomp support more the focus, and nothing you don’t immediately need in addition to it, it makes a lot more sense to me to use Apollo for RadioVIS brokers. That said, AMQ has a heck of a lot more maturity – I’ve managed to make Apollo use 100% of my development VM’s CPU a few times with the snapshot release I’m running, and I’m not even sure how! Setting resource limits for AMQ is vital, and the lack of properly working authentication in Apollo at present is a deal-breaker for production at present. I’ll sit down with AMQ sometime this week and properly write up a configuration for RadioVIS, and if I can get it happy and stable under simulated loads I’ll pop it up here.

    Looking forward to slide size negotiation – I’m currently rendering everything at 640×480 and then resizing to 320×240 but rendering different versions for each screen size is something I’ve considered in my framework for rendering (which I may pull out and turn into a library if I get a moment this evening).

  3. Minor addendum (and I’ve updated the post) – I had some time so I pulled out the slide generator stuff, improved on it a fair bit, and made it into a Ruby gem designed to be utterly trivial to customise and extend. I’ve reimplemented our implementation at Insanity using it, and it’s certainly more pleasant to work with now.

    It can be grabbed from http://jamesharrison.github.com/radiovis-generator/

  4. Thanks for the source link – email the radiodns site and they’ll pop it up there too.

    RadioEPG complete yes, but we’re being very careful about getting it just right so that everyone can use it, from student radio to large radio conglomerates in the US, to public broadcasters here in Europe.

    Shouldnt be tricky to implement for FM – the whole point of RadioEPG is to be platform agnostic. Ignore the SI and PI files for now – they are merely a consequence of our use of the DAB EPG spec (again, to provide familiarity). Concentrate on the XSI document – it does what the SI file does but *for any bearer*: FM, DB, IP, AM, etc. This provides the special sauce* to drive Hybrid Radio and Service Following – i.e. transparently switching between platforms depending on conditions.

    Oh and yes, I was also involved in the Radioplayer spec, but we took a different path. Sorry about that :S.

  5. Will do!

    Absolutely – nothing worse than a spec with a major issue in it that slips under the radar. It’d be good to see more example documents, and some collaboration between entities in providing more practical documentation about real-world implementations, but I’m certain I have a valid XSI file and I’m still fairly certain I have a valid pair of SI/PI files. Basing things off the DAB spec just throws me a bit, but then where else could you have started? FM’s never had anything close to what DAB had, and RadioEPG will surpass both DAB and FM existing techs, but DAB certainly had a starting point. All makes sense, at least!

    There’s a spec for Radioplayer? I’ve spent the last couple of days of idle hacking ripping out the EMP flash player and replacing it with the venerable SoundManager2 project, which supports Flash and HTML5, plus adding my existing web player code for stream selection based on browser support and available bandwidth (measured in javascript). Live playback works fine, just need to figure out why the controls keep vanishing when I pass in on-demand content and I’ll be done! Lots of “Huh. So what on earth is going on there?” moments followed by lots of breakpoints :-)

    Edit: Thinking over this, I’m guessing the spec relates to all the back and forth comms between Radioplayer’s servers and the outside world rather than to the how-it-gets-built side of the default implementation provided by the RP Admin section, which is the thing I’ve been wrestling with.

Comments are closed.