...making Linux just a little more fun!
By Phil Hughes
|
...making Linux just a little more fun! |
By Phil Hughes |
In late September I wrote an article about radio station automation for the Linux Journal 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 LG Projects Wiki to further develop this work.
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:
You can look at this potential customer base in three ways:
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.
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.
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.
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.
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.
Generally, one studio will be live. 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.
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.
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.
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.
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.
Next comes the announcements. They can be divided into:
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.
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.
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:
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.
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.
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.
If you saw this project as just fun 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 radio guy as well as a computer guy, this interests me a lot.
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.
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.
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.
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.
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 phil@ssc.com and let me know your interests. Or go out to the LG Projects Wiki and chime in. Maybe Linux-controlled radio will be here before you know it.
Phil Hughes is the publisher of Linux Journal, and thereby Linux Gazette. He dreams of permanently tele-commuting from his home on the Pacific coast of the Olympic Peninsula. As an employer, he is "Vicious, Evil, Mean, & Nasty, but kind of mellow" as a boss should be.