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.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Designing Foils with XFLR5
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis