³ÉÈËÂÛ̳

Yasser introduced visual radio on Monday and the trial has been going on this week. There is one last chance to catch it - on Annie and Nick this Sunday night (7pm - 10pm). The technical team behind it have written this post to give some idea of how the technology driving this system works. So over to the tech team of Conor Curran, Sean O' Halpin, , , , , Ant Smith, Terry O'Leary and Will Kinder

One of the key elements of this project was to provide the ability for the editorial team to control the user client in realtime from the studio.

We considered HTTP polling but in the end found that the only way we could achieve the low latency and scale we required was to push messages to the client. We tried and rejected , mainly due to its verbosity, and there being no decent support for pub/sub in any Ruby XMPP library.

The first solution that showed promise was . This works by embedding a small Flash client in the HTML page for the sole purpose of providing an XML socket connection back to the server which it bridges to javascript. The server side is written in Ruby and integrates very well with Rails. Unfortunately, our tests showed that Juggernaut cannot yet scale to the levels we required. However, it provided the inspiration for our eventual solution.

As it turns out, we were already using a very similar solution to display LiveText on our network home pages via a third-party realtime messaging service provided by Monterosa called En Masse. Putting together what we'd learned from Juggernaut with the proven scalability of En Masse, we were able to piggyback our protocol over the existing messaging channel.

When a user loads the Visual Radio console, the En Masse server opens an XMLSocket connection to the connecting client and throughout the lifetime of the connection it will push XML messages to the Flash client.

Messages are fed to the En Masse server from our back end . All the back end processes are written in Ruby using our .

To control all this and provide the studio with the realtime control they needed, we built a Ruby on Rails web application which sends messages to the client via the messaging infrastructure. If the Radio team want to push content to all the people connected via the Visual Radio console, they will activate the specific module they want to show within the Rails admin application and a chain of events occur. At a high level, what happens is:

• A message containing a url to a resource is put on a queue by the admin application
• A process watching this queue, gets the message and parses it
• A request is made back to the resource url above, which returns an XML packet
• This XML is then posted to a server
• This server then messages all clients connected via their XMLsocket connection
• The client parses the XML and displays the information to the user

Now Playing Information

Whenever a track gets played on Radio 1 we receive a file from the playout system, containing the details about what was played via an HTTP POST request. This message is then put on a message queue, so that it can be archived and sent to other systems.

The track data is sent to us in a proprietary text format, created by the playout system vendor. So the first stage is to parse it into a data structure that is easier to process. This is then put back on to another message queue, again so that other systems can make use of it.

The next message queue processor looks up the artist information in using the artist name and the track title for disambiguation. If it unambiguously finds a matching artist in MusicBrainz then we add this information to the message, which can then be used to fetch an image and biographical information from /music/artists/:artistid

Architecture

This may be just a trial but because it's being broadcast live we need it to be reasonably fault-tolerant. To that end we're using a high-availability Apache based web tier which proxies requests back to multiple application servers. Each application server connects to a high-availability MySQL based database tier. In the event of one of our servers failing another will automatically take over with minimal disruption of service.

To manage the high-availability web and database tiers we're using open-source software called . Our application servers are all and are running Rails. Underpinning everything we use Linux running under Xen which provides efficient virtualisation of our physical hardware.

Streaming Audio and Video

The vision mix output along with the audio feed from the studio was encoded using a Flash media encoder. The On2 VP6 codec was used for the video and MP3 for the audio. This feed was streamed over an SDSL connection to the ³ÉÈËÂÛ̳'s Content Delivery Network. The Flash client once launched attempts to connect to this stream hosted by the third-party.

You can read more about and over at some of the developers' blogs.