The ntpi: accurate time with a Raspberry Pi and Venus638FLPx

One of the things I’ve always loved to tinker with is time sources and synchronization. Typically this has been tied to sensible things like the Network Time Protocol and designing and maintaining time distribution systems for broadcast networks. Lately though I’ve been toying with ‘real’ time sources – GPS and MSF broadcasts. This is a quick tutorial on how to set up a Raspberry Pi, which at only a few watts makes for an economical time server, to talk to a Venus 638FLPx GPS receiver (available from Sparkfun on a suitable breakout board here). Continue reading The ntpi: accurate time with a Raspberry Pi and Venus638FLPx

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.