So when I moved in to my current university digs, the previous tenants had left a few things behind. Notably, they’d had Sky. So we had a Sky box in the living room and a dish on the wall. In the UK, if you want fast internet these days, you need Virgin Media. VM gives you cable TV in the bundle, so I didn’t want to pay for Sky. But Freesat’s got some nice stuff on it, including BBC HD and that sort of thing. So how about we get ourselves some free TV?

Now, Sky uses the same satellite for the UK as a lot of Freesat stuff. So ignore the dish- all you need is to leave that bit alone, and make sure that you’ve got a cable from the dish LNB to somewhere you can put your PC. Where it’s pointed is probably 28.2 East, which has a bunch of appropriate satellites.

What you then need is a capture card. DVB-S is the standard for satellite, though DVB-S2 is used for some HD encoding (specifically, BBC HD is now on DVB-S2). DVB-T is for terrestrial stuff, and comes in on coax from a standard TV aerial – you can get combo cards, which will let you pull down extra stuff if you’ve got the coax feed. Stuff from your LNB typically comes on F-type cables/connectors, down 75 ohm cable. I have yet to find a decent UK supplier for patch or extension leads – if you know one, let me know.

The LinuxTV wiki maintains a huge list of hardware compatibility with Linux and capture cards, so check there before you go buy anything. I got a Compro S350 card, which works great for DVB-S – I’ve also ordered a Technisat S2 HD card, which should do DVB-S2, and I’m going to look out for a DVB-T card.

Now, we need to tie all this together next. So we need some software and a PC. The PC wants to be a decent spec – I’m using a Pentium 4 box with 768MB of RAM as my server, which is on the low end of things. A faster machine would be better, obviously, but it’s all I have to hand. I stuck a decent (GeForce 6600) graphics card in there, too. Fast CPU is the priority, really- we’re talking high definition decoding, encoding, transcoding and playback. If you’re on a budget, look into Intel quad-core chips (Q6600s, that sort of thing). Intel is the way to go wherever possible. If you’re doing this properly, high-end i7 would be my choice- that or a Xeon or similar. 6-12 core chips would be just the ticket. High-end (newer 8800 series and above) nVidia cards support VPDAU, which lets you offload video decoding and processing to the GPU.

The software to use is MythTV. I’m using a standard Ubuntu 10.04/11.04 (‘Classic’ mode on 11.04) install, and then installing MythTV atop that. On the server, just install the mythtv, mythtv-themes, xmltv and mythweb packages. On any other clients you can install the mythtv-frontend package, and optionally the mythtv-themes package. The client-server model of MythTV means you can combine backends and frontends to build your system. It’s crazy powerful in terms of flexibility. But the short story is, you can have a very nice TV system in very little configuration.

See this excellent guide for more information on how to set up MythTV with Freesat. Basically you just need to tune it in to the right satellite and set up the input properly so it’ll get the channel list. MythTV’s config options take some getting used to, but it’s eminently doable. And once you’ve gotten everything talking, you have a -very- capable system.

So, well done to the MythTV team. One hell of a package, that’s for sure. And Linux DVRs are now in my mind far, far more capable than any other potential choice for DVRs. With MythWeb, I essentially have my own private little iPlayer- but for every single bit of Freesat’s programming. What’s not to like?

Well, here’s one thing- there’s so many fantastic audio editing, production and routing tools for Linux. And even better, there’s loads that can be run on a command line, without needing a desktop computer- so we can do audio processing on our server hardware, of which we’ve got plenty. But they’re a bit hard to find so I figured I’d just do a quick summary of the top few tools we’re using that you might’ve heard of, and a few you probably haven’t. So, in no particular order…

sox

sox is an awesome little tool which bills itself as the swiss-army knife of audio tools. It’s not far off, either. While it’s not so great on the format support side of things, this little thing can do pretty much any common operation you want it to do (and a few not-so-common ones). We’re using it to automatically split up hour long MP3 files into half-hour chunks, as well as using it for trimming silence off audio and performing companding on audio before things get imported to our playout system. We use ffmpeg to get things into WAV for it, though.

ffmpeg/ffprobe

ffmpeg is one of those legendary tools. This thing will read anything and lets you seamlessly turn it into anything else. I’ve thrown the nastiest, strangest and most obscure files at this thing and had it spit out completely usable WAVs time after time. Learn to love this puppy. Oh, and it’s fast, too. ffprobe is it’s companion tool, able to quickly give you the rundown on any file and return metadata.

exiftool

If ffmpeg is the king of reading audio data, exiftool is the queen of metadata. While it’s aimed mostly at image files, it’s also incredibly good at pulling useful metadata out of various formats stored in audio files- MP3 ID3 tags, AAC metadata, you name it. We use this to get metadata out of pretty much anything and normalize it into MP3 ID3 tags for our playout system, which can’t recognize much unless you spoon-feed it in the right format.

mp3info

A blissfully simple little tool for querying and writing MP3 ID3 tags. Very handy, fast, and simple. What’s not to like?

JACK

JACK, the Jack Audio Connection Kit is yet another one of the more well-known tools. Capable of routing audio signals inside a virtual patchbay it’s very powerful, and we use it extensively all over the place. NetJACK is an interesting development that is really starting to take shape now, and is one to watch in the coming years. JACK is supported by tons of stuff, including a lot of the software aimed at the broadcast and professional audio crowd.

jack_meter

jack_meter is a really nice little script that can do command-line monitoring of levels on a given set of JACK ports. It’ll draw you a nice little meter, or spit out numerical information. We’ve actually now got this hooked up to a Nagios script to check to ensure our self-operated studio is in the right ballpark levels-wise and isn’t driving the net TX system overly hard- works a treat!

rotter

Not so handy for _everyone_, but certainly has its place. Rotter is a recording of transmission tool, intended for radio stations and other people who want to make a continuous recording of an audio source (using JACK again) and store it in files split up based on a fairly flexible partitioning system. We’re required to do regulatory logging and such, and this is used for both that and for presenters who want to make podcasts of their shows – and this is a darn sight cheaper (and better!) than the £1500+ commercial products to do this.

audacity

Okay, not a command-line tool, but it’s by far one of the best audio editors out there right now, in my opinion matched only by Pro Tools for just doing quick and simple composition and editing of assets. And since it’s crossplatform and free, the presenters can take it home with them and work there instead of having to use our production room to do simple edits!

I’m sure I’ll remember a few after I post this but that’s certainly a good start. Do you have any tools you couldn’t live without for audio processing?

Recently I’ve been building equipment for Insanity Radio, the student radio station where I currently serve as Head of Technology. We’re a student radio station and this poses lots of problems to successful technology implementation:

• Cost – our budget is very small, and mostly goes on licensing fees to PRS/PPL/MCPS.
• Reliability – the station as a whole has to be able to operate unattended for months at a time over the summer holidays
• Ease of operation – the station is typically only crewed in the live segments of our programming by the presenters doing their show. We have no full-time or on-shift producers or crew
• Ease of expandability, upgrades and maintenance – the technical staff of the station changes on a year-by-year basis

Bearing all these in mind we have to be careful when implementing new tech or building new systems that we don’t make anything that the technical staff after us won’t be able to handle, and which (where relevant) can be operated by an unskilled user.

We’ve recently been granted a FM license by Ofcom, and are currently waiting on lots of paperwork and things to be done so we can get the ball rolling on that particular project – namely, setting up a complete FM STL and new transmission system. Of course, the transmission system is something we’re getting outside broadcast engineers with a lot more experience than us to do (namely Radica, who did our AM mast many years ago). But facets of the system- namely, the STL (Studio-Transmitter Link) and telemetry (allowing us to, via remote operation pins and monitoring outputs on equipment, remotely monitor the status of equipment and control equipment where needed) can be done without needing to splash out on consultants. In fact, most of the solutions you can buy off-the-shelf for transmission site telemetry are quite restrictive, using proprietary protocols that only work with the supplier’s software. In my mind this completely doesn’t fit the bill for a telemetry system. What you basically need is an open, non-proprietary protocol that you can use to query devices.

Is this sounding familiar? It should be – datacenters got this problem solved years ago. And the networking industry came up with SNMP. It’s extensively used on switches but also on UPSes, environmental monitoring gear, and more.

SNMP is the Simple Network Management Protocol and it supports a very flexible schema for remotely monitoring equipment. And somebody’s rather handily built a library to run on an Arduino microprocessor platform with an Ethernet shield for the TCP/IP component.

Now, going back to the issue of cost – £30 for the Arduino Mega and £40 for the Ethernet shield brings us to £70 per node. But now to interface with all that gear we need pull-up resistors (trivial), relays (not so much – £4 each for DIL mounting reed relays) and optoisolators. All of which brings our total cost closer to the £100 mark once we’ve bought all this and soldered it up on to a breadboard and interfaced it all. In theory. I’m currently working on an Arduino Shield to provide the relay and optoisolator etc outputs on screw terminals, and I’m looking to get the PCBs made by BatchPCB.

I have yet to actually build one of these nodes but plan to do so soon as a proof of concept. We have roughly 125 pins of I/O from our mixing console to interface (mostly on 25 and 15 pin d-subminiature connectors), 15 pins of I/O on our silence detector, 15 pins of I/O on the AM transmitter, and soon we will have an entire remote transmission site to monitor. The first one of these devices will be a proof of concept, and hopefully will pave the way to future development of this sort of technology.

Of course, the huge benefit of SNMP is that it can be tied into anything. Let’s go back to the reliability and ease of operation points in the list above – we’re now using Nagios for monitoring all of the station’s IT resources (Not a small challenge in and of itself), and we’ll be expanding that to cover the STL and network itself. Now imagine we can bring hardware and environment into Nagios – now we have complete monitoring, end-to-end, from the studio playout computer being happy and running the radio playout program, all the way to the transmission site, all in one open and extensible monitoring system. No proprietary systems, no vendor lock-in, nothing – just a flexible and reliable system that many people are already familiar with.

There’s another huge benefit of keeping things flexible, of course. We’ve recently installed a set of RGB LED lights in the studio, as well as a LED matrix display. These are driven by a pair of Arduinos hooked up to serial over USB on our monitoring PC. We can have the monitoring software feed presenters information, or set the lights to indicate problems. This has already yielded fruit – we have the silence detector alarms hooked up so the lights go red when presenters are being so quiet (ie getting their levels wrong) that the studio fails over to a backup playout system. This quick visual feedback has provided presenters with real instant feedback on their show and lets them correct a problem, rather than the issue going unnoticed. In the world of student radio that means you’ve now saved several phone calls and potentially large swathes of missing content, not to mention made presenters happier because they now get positive feedback when everything’s going well! Lots of small steps like this can lead to big changes in the professionalism and quality of shows and allows presenters to be more daring and experimental in their shows, meaning better and more interesting shows and content. And if that’s not a huge success for a few simple additions, I don’t know what is.