OpenOB for the future

So in the wake of the nomination for OpenOB (and OCD, a CMS I wrote for Insanity Radio) for a Student Radio Award for Best Technical Achievement, I’ve been motivated to have a look at what OpenOB wants to do in future.

I’m increasingly convinced that I’m going to end up forking the project.

There’s two main modes OpenOB is currently used in – PCM, for lossless STLs where an ethernet network is in place and absolutely perfect transparent audio is desired, and CELT, the low-latency forerunner of Opus. Opus is now an IETF standard and clearly incredibly capable, totally supplanting CELT and adding a lot of functionality that broadcasters will really like – forward error correction, packet loss concealment, bandwidth flexing and variable constrained bit rate transmission. For higher-latency very-low-bandwidth links there’s also a mode called discontinuous transmission which will only transmit audio – silence periods are not encoded at all.

The trick is that supporting both PCM and Opus in one box is getting increasingly cumbersome and so I’m going to fork OpenOB’s PCM mode into an independent project, OpenSTL. Apart from anything else, the functionality desired from an STL (where there is rarely, if ever, a configuration change) is massively different from that desired for outside broadcasts (bidirectionality, rapid reconfiguration, bandwidth management, etc). Even on networks with 100Mbps bidirectional reliable connectivity, Opus is as high-quality as you’d ever need and will almost certainly still sound better thanks to PLC/FEC ironing out any discontinuities in the bitstream.

So the goal now is to end up with:

  • OpenSTL
    • PCM and Opus transmission modes with FEC/PLC
    • Configuration tweaked for high-bandwidth/high-CPU-complexity reliable transmission
    • Standalone daemon with configuration file on each end
  • OpenOB
    • Opus with bandwidth flexing, FEC, PLC
    • Configuration tweaked for minimal-bandwidth, low-CPU-complexity reliable transmission
    • Latency/bandwidth tradeoff options (DTX, frame period tweaks)
    • Bidirectional link autonegotiation
    • Standalone daemon with configuration file on the receiver
    • Command line and graphical user interface (PyGTK) on the transmitter
  • OpenAOIP
    • Set of common code for managing Audio over IP sessions (RTP, Opus/PCM encoding)
    • Just a library – no user-facing code

It may be the case that OpenAOIP turns out to be fairly defunct if there’s a lot of minor tweaks to be made to the link code that is best just done in each app rather than trying to manage loads of different options.

Bidirectional link auto negotiation I’ve been thinking about quite a lot lately and I still don’t have a nice answer. The ideal case would be the transmitter sets up two tunnels, thus punching a hole through any NAT and allowing bidirectional RTP with zero configuration. Quite how to achieve that with GStreamer is another matter altogether, but hopefully it’s a solvable question. This would allow talkback channels to be set up automatically alongside the return path, making OBs with OpenOB much easier to coordinate.

I’ve been trying to get OpenOB working on Raspberry Pi hardware, too – so far without luck thanks to my Pis being somewhat uncooperative as of late. I’ve got a Revision 2 Model B board on order and once that arrives I’ll be having more of a play with that.

In the meantime I’ve updated OpenOB to support Opus in addition to CELT, with inband forward error correction and packet loss concealment enabled, a 5ms frame size and moderate computational complexity. It’ll assume a 2% packet loss on the link by default, which should make 3G broadcasts quite resilient (I’ve not had a chance to test this). At lower bitrates it will switch audio bandwidths from fullband to narrowband automatically. You can check it out from git now – bear in mind you need opusenc/opusdec on your PCs, which is currently only available in Debian testing (Wheezy) or Ubuntu 12.10 (untested). I recommend Debian Wheezy for current testing and characterization of Opus in OpenOB.

Introducing OpenOB

The next post will be part 3 of my Engineering FM series but it’s time for a quick diversion to introduce a tool I ended up producing, initially as a contingency plan, but later as a serious project, for implementing outside broadcast audio links and studio-transmitter links using the Real Time Protocol.

That tool is called OpenOB. The main resource for finding out more is the GitHub page hosting it. But I figured it deserved a proper introduction as I’ve had quite a few people asking after it via a post on the Rivendell mailing list. Continue reading Introducing OpenOB

Engineering FM – Part 1

This post is the first in a series of posts I’m going to do covering some of the engineering aspects of setting up a Community FM Radio station in the UK, and the lessons I and others learned while setting up the system.

First a bit of background. The station I helped set up, Insanity Radio, will be launching its FM transmissions in the coming weeks, and is a station run and operated entirely by students at Royal Holloway, University of London. The station started back in the 90s broadcasting on FM using a low-power rented transmitter, licensed under Restricted Service Licenses (RSLs) which only allowed for a week or two of broadcasting at a time. The station eventually moved to full-time AM operation, under a Low Power AM license. Back in 2006, a previous manager applied for a license for Community Radio, to permit FM broadcasting on a permanent basis, and in 2009 that license was awarded to Insanity by Ofcom, the UK’s radio regulatory body.

Our license was awarded for a 25 watt EIRP mast to be installed on campus. So in 2009/2010 we got the ball rolling with planning. Continue reading Engineering FM – Part 1