Real Time kernels and audio on the Raspberry Pi

A year or two ago I posted about how you could send audio over the internet with Raspberry Pis using the OpenOB project. Since then the OpenOB project has taken off, with lots of contributions from the community and lots of improvement as a result.

What hasn’t aged well is the Pi. A firmware update to fix some keyboard compatibility issues caused some serious issues with audio over IP, as both the Ethernet controller and USB sound card shared a USB bus which couldn’t operate quickly enough to handle the precise timing demands. Fortunately, the Wolfson Audio Board has come along to save the day – and it’s certainly promising.

Sadly, the kernel support for the Wolfson device isn’t in the mainline kernel yet, so that means using their custom OS image, or building our own kernel. On top of that we’d quite like a preemptible kernel to allow us to get lower latencies in userspace. This is crucial for reliable jitter-free low-latency audio, but because it’s quite niche this also means we need to apply some non-mainline patches to the Raspberry Pi kernel. The Wolfson drivers will eventually make it to the Pi kernel by default, and hopefully someone familiar with packaging for Debian/Raspbian can contribute a package to provide a real-time patched version of the kernel; but in the meantime we need to get our hands dirty. Here’s how to get a stock Raspbian image turned into a low-latency audio capable flavour, broken down and explained a bit. Continue reading Real Time kernels and audio on the Raspberry Pi

Broadcast-quality OBs with Raspberry Pis

OpenOB‘s been ticking along nicely but it’s historically needed a bit of oomph and capital in the form of two computers running Linux. This isn’t often what you’ve got on your PC and it’s not something you can easily chuck in your reporter’s rucksack to take along to an event.

This limits its usefulness somewhat. So what you need instead is something cheap, small, and lightweight, that can run Linux and do everything you need it to with regards to OpenOB and network management.

Enter the Raspberry Pi, the £25 wonder-SBC. It’s got audio out (not in), runs Linux off an SD card, is small, runs off 5V power supplied via USB, and did I mention it’s £25? Okay, £30 if you buy from Farnell with shipping thrown in, and probably more like £60 when you’ve bought a power supply, sound card, SD card, etc. But we’re still talking an outside broadcast remote and receiver for a grand total of around £200. Compare that with the £1,500 per end of the current cheapest commercial solution, or the £5,000+ an end and up boxes found in most professional OB trucks. Sure, you don’t get their slickness or polish or even all their features, but you can move audio and you can do it well with OpenOB. With Opus, now from 16kbps all the way to 384kbps or linear PCM.

The primary OS supported for the Pi is Raspbian, a Debian derivative, which is awesome – because Debian/Ubuntu is the standard platform on which I develop OpenOB.

So can we actually make this perfect storm come to pass?

Update, 3rd Apr 2014: This post has been superseded by the OpenOB documentation. Please don’t try and use this post to configure your Pi – it is wrong in places as a result of updates and is not being maintained.

Continue reading Broadcast-quality OBs with Raspberry Pis

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.