1. Ben

    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. Ben

    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.