Open-Source Radioware

Rivendell and other Salem Radio Labs projects bring GPLed open-source tools to broadcasters everywhere.


Last weekend I was sick with a fever and was dreaming crazy dreams in
the middle of the night. For some reason I kept noodling in my brain
about Hugh Hewitt and Salem Communications. Hewitt is a writer,
blogger and popular conservative talk-show host. Salem is a large
broadcast group owner with a Christian mission. It also owns the
Salem Radio Network, which syndicates Hewitt, Michael Medved and
other personalities.

I had no idea why this stuff was happening in my dreams, but I blabbed
about it in my blog anyway, because I was still sick and lacked the
energy to blab about anything else.

So a couple days of later I heard from a reader in Ireland who said
maybe I was dreaming about Salem for a pretty good reason. Seems that
Salem Radio Labs develops and distributes GPLed open-source
applications for operating radio stations. The writer was especially
turned on by Rivendell, described this way on its index page:

Rivendell aims to be a complete radio broadcast automation solution,
with facilities for the acquisition, management, scheduling and
playout of audio content. As a robust, functionally complete digital
audio system for broadcast radio applications, Rivendell uses
industry standard components like the GNU/Linux Operating System, the
AudioScience HPI Driver Architecture and the MySQL Database Engine.
Rivendell is being developed under the GNU Public License.

Radio is a subject that has been dear to my heart and brain ever
since I was a kid. Longtime Linux Journal readers know I'll find any
excuse to go off on a radio tangent. Well, now I have a real good
one.

As soon as I looked through Salem Labs' site, I got in touch with Fred
Gleason, Director of Broadcast Software Development for Salem Radio
Labs, and told him I'd like to do a Q&A with him. He got back (and
forth) almost immediately. Here's a selection from the dialog:

Doc Searls: Whose idea was this? (The company's? A station's?)

Fred Gleason: It basically arose as a sort of synergy between John Ehde
(Salem's Senior VP of Engineering) and myself (at the time, Chief
Engineer of WAVA in Washington DC). John had been wanting to "adopt"
and standardize an automation system for a couple of years, and I
wanted something Linux-based, as all of the existing proprietary
systems ran only on Windows and had all of the problems inherent in
that platform.

DS: How did it get rolling?

FG: The whole thing jelled at a company-wide meeting of engineer and
programming types at Spring NAB in 2002. We did what amounted to a
big focus group to determine what an automation system needed to do
to optimally handle the sort of programming Salem often does
(long-form talk programming). The original Rivendell design arose
directly from those discussions. A few months later, I was
transferred from WAVA to the corporate payroll and started work on
the project full-time.

DS: I assume you and John were into Linux already. What were your
backgrounds there? Did you come from other Unix platforms or what?
(Everybody's story is different.)

FG: I had been running it since late 1994, when I came across a book
called Running Linux at the local MicroCenter store. Back then, I
was your classic CE [chief engineer]--a hardware guy, looking after
transmitters and cart decks. I had taught myself C programming as a
teenager (on a Commodore 128) but had never really done anything
with it professionally. Linux revived my interest in the software
side of things, to the point where I eventually ended up teaching
myself C++ and Qt. So, when the time came, it was just sort of
natural that I'd undertake something like Rivendell.

John, on the other hand, has no *nix background at all. He just
knew it as an OS that had a great reputation for stability and
reliability, something the Windows systems we were using at the time
were notably lacking (this was the NT 4.0 era). John is a good
friend, and it says something about him as a person that he was
willing to trust me (someone with no academic qualifications in
computing whatever) to pull off a project like this.

Somewhere in his writings, Eric Raymond talks about this sort of
thing as a more general phenomenon: a "subject expert" in a
particular industry that ends up morphing into a programmer in the
process of implementing a FOSS solution for that industry, rather
than coming from a traditional academically-trained computer science
background. Rivendell is a classic case of this.

DS: How much are your stations using it? How about other stations,
including stations on the Net?

FG: Salem currently has eleven stations (out of about 100 total) on
the air with it. By the end of this year, that number should be close
to 50. The plan is eventually to move all Salem stations to it, as
their current (proprietary) systems wear out and need replacement,
while all newly acquired stations get it from Day One. We are also in
the middle of installing it at our network head end (Salem Radio
Network, where Hugh Hewitt and others are originated), where it
should be on-air by the middle of this year. You can get a sense of
what a typical installation looks like from this
"virtual tour"
of our Seattle facility.

As for other stations, I don't have an accurate count, but I know
it's on the air (both web stream and terrestrial radio) because I get
feedback from those users all the time on the project mailing lists.
My impression is that it is particularly popular in Europe and the UK.

DS: Does it address the complex Internet broadcast music reporting
requirements of SoundExchange in the U.S.?

FG: Yes. It is capable of generating music reports for SoundExchange
directly from the database of aired songs.

DS: Do many Internet-only stations use it? Can you say which ones?

FG: Do a search of the
list archives.
You'll find lots of references.

DS: The guy who wrote to tell me about Rivendell said he saw it as a
replacement for RCS.

FG: That's a fair assessment. It's in the same class as many of the
radio automation products--ENCO, ScottStudio, Prophet Systems, just
to name a few.

DS: He added, "All we need now is a decent scheduler (like an OSS
analogue for Selector) and the whole radio business gets much more
interesting."

FG: Yes, this is the point of critical need in the toolchain right
now. I see folks looking for a scheduler on the project lists
regularly. Part of the problem is that music scheduling, when done
correctly, is as much about the *data*--song titles,
beats-per-minute, album art, etc.--as it is about scheduling logic.
A FOSS app can provide the logic, but for the data you're still going
to end up either licensing an existing database (big $$) or compiling
one yourself (big-time labor-intensive). There has been some recent
discussion on the project lists about undertaking some of this under
some sort of CC license--it'll be interesting to see where it goes.

DS: Any guess at how much money it saves stations?

FG: The figures I've seen indicate an up-front savings of 50-75% over
comparable "proprietary" (in this case, ENCO DADPro32) systems. This
is with both hardware and software costs factored in. Support savings
are even greater, as ENCO support involves a hefty annual fee. And,
of course, no license tracking, malware or patching costs to worry
about.

DS: Are Salem stations generally using Linux and open source? Got
some examples? (We love success stories.)

FG: It varies widely by site. Some use it for their entire server
infrastructure (Samba, Sendmail, Apache), while others are only just
now getting their feet wet. A significant development has been in the
small but crucial (for us) area of talk show call management, where
CallCommander
is being used extensively.

DS: Is there support for tie-ins to Web pages? (Listing, for example,
programs or music being played.)

FG: Yes. Rivendell has a feature called
"Now & Next" that is capable
of sending data about current and upcoming events to external devices
(such as web servers and RDS encoders). I know of at least one site
(non-Salem) that is using this to update player messages via Icecast.

DS: How about for podcasting, using RSS and enclosures?

FG: Rivendell is capable of generating and uploading the MP3s
automatically. Direct generation of RSS data is currently not
supported but is under discussion and will probably be added
eventually.

So there you go.

There are more and more stations every day, on the Net as well as the
air, that need to get more done on less money and with less hassle.
Add to that the growing zillions of podcasters, and I'll bet there's
a lot of fun to be done with Rivendell and other projects like it.

Go to
Salem Radio Labs
and check out Call Commander (call screening), SoundPanel (swift access
to an array of audio sources) and Linux Audio Backstop (automated
scheduling of audio recording and playback). Plus the other good
stuff there.

Hey, if you're doing radio, maybe one or more of these can work with
your dreams, too.
Resources
Hugh Hewitt

Salem Communications

Doc's Blog

Salem Radio Labs

Doc Searls is Senior Editor of Linux
Journal
. He writes the Linux for Suits column for Linux
Journal
. He also presides over
Doc Searls' IT Garage,
which is published by SSC, the publisher of Linux
Journal
.

______________________

Doc Searls is Senior Editor of Linux Journal

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix