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