Helping Broadcast Radio with Linux
After writing about the POS systems last week, I started going through my list of other past lives--things I have done either professionally or as a hobby in the past. This got me thinking about broadcast radio, or more accurately, what Linux could do for broadcast radio.
Although most of my experience has been at the transmitter end--I have a commercial radio-telephone license and have tuned and repaired broadcast transmitters--I am pretty familiar with the other pieces that make a radio station work. Back when I did systems testing on an operating system for big iron (yup, another past life), some of our commercial customers ran programs on our computers to keep track of what music had been played. This was mostly an accounting issue--that is, it kept track of royalties.
Computing has changed a lot since then. Now, computers essentially are free instead of costing millions of dollars. Thus, this simple radio tracking application could be run on any old PC today. But much like the old days of having to write something down and then enter it into the computer, there must be a better way.
The better way would be for a computer to run your station completely. That is, you store copies of all your program materials on the computer, and then tell it what to do when. Materials can include music, pre-recorded programming, commercials and practically anything else. Toss in a few voice features, such as a digital voice announcing the current time and the output of a weather station, and the only time you need a human is when you have a live program.
Expanding a little on the "what to do" idea, there really is no reason you need to be too specific. You could, for example, tell the system to select randomly from a pool of songs, never playing one more often than every 27.5 hours.
This radio design isn't far-fetched; in fact systems like this already exist. For example, Radio Paradise pretty much has this radio model in place--with Linux. In fact, Radio Paradise is well worth a look and listen simply to see how such a solution works. But, a lot of radio stations are out there, and Radio Paradise is the only one I know of that's running the automation on Linux.
So, what's wrong with this plan? I have two local (that is, Costa Rica) examples to draw from, and both are shortwave stations. There is nothing special about that fact; shortwave stations simply happen to be the stations with which I have talked. In reality, an Internet-only station could use the same software for its work.
Back to the examples. First, right up the street from my house is what is supposed to be the world headquarters for Adventist World Radio. I put a slight disclaimer here because the sign on the street announces this, but I didn't discuss it with anyone at the station. In fact, I was at the station for an auction of radio equipment when the following discussion developed.
The person I talked to, one of the few that spoke any English, said the station was using a station automation package that runs on Microsoft Windows. He then went on to explain that the system wasn't reliable enough. That is, it would fail and someone would have to reboot a computer--which pretty much defeats the purpose of station automation.
Of course, I bought up the idea of using Linux. To my surprise, he was familiar with Linux and said the station had tried loading it on one of its computers. His big concern, however, was that if the station found a Linux-based solution it would have no support. That is, what if Linux failed? Or a possibly free software package? In his case, he was a one-year volunteer; even if he got up to speed on the solution, he would be gone within a year.
The second example is Radio for Peace International. RFPI is located about 20km from where I live, but the back-haul to its Internet connectivity is supplied by a wireless link whose antenna is about 20 feet from me as I write this. I am much more familiar with RFPI's operation and expect it is typical of many stations.
RFPI downloads much of its program material from the Internet--using a Linux system, of course. Rather than save the material on the computer, RFPI saves it on mini-disks. Broadcasts, then, are done with a live announcer filling in between pre-recorded material. The live broadcast also is recorded on tape for re-broadcast later in the day.
In the RFPI example, the only missing link to full automation is some software. That is, the program material already is in a form that could be saved on the computer, and that same computer certainly is capable of doing the editing to add the local content.
Why doesn't RFPI make this change? Simple--it already has something that works. Making this change to full automation would require procedural changes and training. And, when the automation breaks, the station needs someone to bail it out.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development