old-www/LDP/LG/issue96/hughes.html

320 lines
12 KiB
HTML
Raw Permalink Blame History

<!--startcut ==============================================-->
<!-- *** BEGIN HTML header *** -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML><HEAD>
<title>Linux Radio Station LG #96</title>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
ALINK="#FF0000">
<!-- *** END HTML header *** -->
<!-- *** BEGIN navbar *** -->
<A HREF="ecol.html">&lt;&lt;&nbsp;Prev</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="index.html">TOC</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="../index.html">Front Page</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue96/hughes.html">Talkback</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="../faq/index.html">FAQ</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="artime.html">Next&nbsp;&gt;&gt;</A>
<!-- *** END navbar *** -->
<!--endcut ============================================================-->
<TABLE BORDER><TR><TD WIDTH="200">
<A HREF="http://www.linuxgazette.com/">
<IMG ALT="LINUX GAZETTE" SRC="../gx/2002/lglogo_200x41.png"
WIDTH="200" HEIGHT="41" border="0"></A>
<BR CLEAR="all">
<SMALL>...<I>making Linux just a little more fun!</I></SMALL>
</TD><TD WIDTH="380">
<CENTER>
<BIG><BIG><STRONG><FONT COLOR="maroon">Linux Radio Station</FONT></STRONG></BIG></BIG>
<BR>
<STRONG>By <A HREF="../authors/hughes.html">Phil Hughes</A></STRONG>
</CENTER>
</TD></TR>
</TABLE>
<P>
<!-- END header -->
In late September I wrote an article about
<a href="http://www.linuxjournal.com/article/7168" target="_blank">
radio station automation</a>
for the <i>Linux Journal</i> web site. You can find the article
The comments I received indicates that there is interest.
What I would like to do here is to see if there are some people who
would actually be interested in working on such a project.
I have establesed a palce on the
<a href="http://projects.linuxgazette.com">LG Projects Wiki</a> to further
develop this work.
<p>
The comments the article received indicated that many of the pieces were
in place.
Most I knew about and this didn't surprise me.
However, I want to build a solution rather than present a shopping list.
That solution has to include various pieces of software, all playing
together along with support.
The pieces I see are:
<ul>
<li> Audio conversion tools
<li> Audio editor
<li> Streamer
<li> Station automation
<li> Logging
<li> Transmitter
</ul>
The first three items are pretty obvious and there are lots of choices
out there.
Logging is equally obvious.
The other two items warrant further discussion once I get the basic
concepts out.
<h2>Customer Base</h2>
<p>
You can look at this potential customer base in three ways:
<ul>
<li> Where you can get some money from
<li> What sort of fun code you can write
<li> What good political ends you can reach
</ul>
<p>
The market is huge and very diverse.
As a result of that diversity there are lots of choices of where you
would like to fit into this project.
For example, if you have a political ax to grind, helping your favorite
political or religious cause get a radio voice or build a more efficient
radio voice is likely your place.
If, however, you just want to be in it for the money, there are tens of
thousands of radio stations that could use your help and would pay for
it.
<p>
Just looking at FM broadcast stations, there are 100 available
frequencies on the band.
In the US, these frequencies are allocated based on the signal
strength of other stations on the same and adjacent frequencies.
I don't have the numbers handy but that easily means thousands of
stations in the US alone.
Toss in AM broadcast and shortwave stations and you have the potential
customer base for a product.
If that isn't enough, Internet-only stations could use the same system.
<p>
Hopefully, if you are still reading, this is starting to make sense.
I willdescribe the overall project idea and then talk about the
specifics from above.
<h2>An Overall Look</h2>
<p>
Let me present how a traditional radio station works.
By traditional, I mean how stations have worked for many years.
That will make it easier to see where automation makes sense.
<p>
A typical station is composed of one or more studios
and a transmitter facility.
A studio is nothing more than a soundproof room with some audio
equipment.
The transmitter may be in the same building or at a remote location
connected by a dedicated wire or radio link.
While there is some room for talking about the transmitter link, I want
to concentrate on the studio end.
<p>
Generally, one studio will be <i>live</i>.
That means whatever is
happening in that studio will be sent directly to the transmitter.
The alternative to a live studio would be the
station either re-broadcasting some external feed or something that
they have pre-recorded.
In any case, whenever the transmitter is on the air, there must be some
source of program material.
Additional studios are available to build the pre-recorded program
material.
<p>
Each studio will likely contain one or more live microphones, multiple
sources for pre-recorded material (CD players, turntable and tape
decks) and something to record a program (tape recorder or mini-disk are
the most common).
Also included is a audio mixer board and monitor system so multiple
sources can be mixed and edited.
<p>
Small stations will typically have one studio with a person that queues
and starts pre-recorded sources and makes live announcements that can
include news and weather.
For a typical music station, the majority of this person's time is spent
waiting for the current song to end so they can queue the next one
possibly inserting some commentary between songs.
They may also be logging what they play so the station can pay the
necessary royalties.
<h2>Station Automation</h2>
<p>
This is the most obvious piece of the system--replacing the live tedium
of queuing CD tracks with an automated system.
The most basic step would be to just save all the tracks on a disk in
a computer system and allow the person to pre-select what they would
like played during a specified time block.
This is relatively trivial to do.
We can, however, do a lot more than this.
<p>
Most stations develop a play list that the live DJs need to follow.
This list includes songs that can be played along with guidelines for
how often they can be played.
Armed with that list, a program could easily make all the necessary
decisions to offer what appears to be a random selection of music within
the necessary constraints.
<p>
Next comes the announcements.
They can be divided into:
<ul>
<li> Commercials
<li> Information that will be supplied live or almost live
<li> Information that could be automated
</ul>
<p>
Automation of commercials is not much different than the music play
lists.
The primary difference is that there will likely be specific times when
a commercial must be broadcast.
Nothing magic here--just another type of event to put into a scheduling
program.
<p>
The live or almost live program material is that which must be put
together by a person.
For example, a news broadcast.
This could either be done live by a person in the studio (or remotely
over an Internet connection) or it could be pre-recorded.
If the news was pre-recorded as a set of items then later news
broadcasts could re-use the appropriate portions of a previous
broadcast.
In any case, there is still nothing particularly difficult about
this--it is just another event to schedule.
<p>
I separated out information that could be automated because it is an
additional project.
That is, it does not have to be part of this original package.
Two things come to mind here:
<ul>
<li> Time announcements
<li> Weather
</ul>
<p>
Both of these announcements are really nothing more than building a
human voice announcement out of some digital data.
Both have been done--it just becomes a matter of integration.
<p>
Some stations allow call-in requests.
This means a human responds to a request, checks to see if the song is
available and hasn't been played more than is considered correct by the
play list and then schedules it.
This seems like a perfect place to use a web page.
Listeners could place the requests and the software would appropriately
adjust what was to be played.
If the requested material was not available it could advise you of that
fact or even order heavily requested material.
<h2>Transmitter</h2>
<p>
While a traditional transmitter is far away from the scope of this
project, a transmitter option deserves mention.
In my searching for FM broadcast transmitters for a project in Nicaragua
I ran across a company that offers an FM broadcast transmitter on a PCI
card.
They have a new card on the way and I have offered to write the Linux
driver for it.
<p>
If you saw this project as <i>just fun</i> or something that would work
for your college dorm, a card such as this might be just the ticket.
You could offer a web interface to select program material and broadcast
to nearby FM receivers.
Being a <i>radio guy</i> as well as a computer guy, this interests me a
lot.
<h2>Overall Scope</h2>
<p>
That covers all the pieces from the geek end.
But, as I said in the beginning, I want to present a solution rather
than a shopping list.
That 100mw station in your basement that your family can listen to is
not going to be a good commercial customer but tens of thousands of
commercial stations certainly could be.
<p>
Integrating all the software necessary to offer a solution is the first
part.
Installation and support comes next.
A radio station that has full-time employees running the station and
advertisers paying hundreds or thousands of dollars for a commercial
will quickly see the benefits of a system such as this.
The biggest hurdle will be showing them that the solution will be
supported.
That is, that their station will not be off the air because they made
this choice.
<p>
For a small station, this might mean knowing that they could call
someone and have them come in and fix a problem.
For a larger station it could mean training of on-site personnel.
There are other levels of support including spare systems, shared
servers and so forth.
In other words, an assortment of different markets where the same
software is offered but the support potential varies.
<h2>What next?</h2>
<p>
That's up to you.
I am excited about the project.
Unfortunately, I have a "day job" which does not give me the necessary
time to put all this together and even if it was together, I don't want
to go into the software support business.
<p>
My hope is that the right people are out there that want to do the
pieces.
That is my real reason for writing this article.
I am happy to offer input, help set direction, offer a mailing list of
discussion forum and even publicize the product.
If you are interested in participating, write at <a
href=<EFBFBD>mailto:phil@ssc.com">phil@ssc.com</a> and let me know your
interests.
Or go out to the
<a href="http://projects.linuxgazette.com">LG Projects Wiki</a>
and chime in.
Maybe Linux-controlled radio will be here before you know it.
<!-- *** BEGIN author bio *** -->
<P>&nbsp;
<P>
Phil Hughes is the publisher of <I>Linux Journal</I>, and thereby <I>Linux
Gazette</I>. He dreams of permanently tele-commuting from his home on the
Pacific coast of the Olympic Peninsula.
As an employer, he is &quot;Vicious, Evil,
Mean, & Nasty, but kind of mellow&quot; as a boss should be.
<!-- *** END author bio *** -->
<!-- *** BEGIN copyright *** -->
<hr>
<CENTER><SMALL><STRONG>
Copyright &copy; 2003, Phil Hughes.
Copying license <A HREF="../copying.html">http://www.linuxgazette.com/copying.html</A><BR>
Published in Issue 96 of <i>Linux Gazette</i>, November 2003
</STRONG></SMALL></CENTER>
<!-- *** END copyright *** -->
<HR>
<!--startcut ==========================================================-->
<CENTER>
<!-- *** BEGIN navbar *** -->
<A HREF="ecol.html">&lt;&lt;&nbsp;Prev</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="index.html">TOC</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="../index.html">Front Page</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue96/hughes.html">Talkback</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="../faq/index.html">FAQ</A>&nbsp;&nbsp;|&nbsp;&nbsp;<A HREF="artime.html">Next&nbsp;&gt;&gt;</A>
<!-- *** END navbar *** -->
</CENTER>
</BODY></HTML>
<!--endcut ============================================================-->