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

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState