Running a Net Radio Station With Open-Source Software
Five great minds got together and decided that broadcasting over the Internet would be cool—plain and simple. Five great minds quickly turned to seven and an Internet radio station at http://www.opensourceradio.com/ was born. The open-source Community has made this internet radio station possible by supplying all the software components. Two main hardware components are necessary to broadcast on the Internet: a broadcast server and an encoder client. It is not a requirement to separate the server and the client, they can be run on the same machine, but we chose to use two different systems at two different locations to generate our output.
We play MP3-encoded material during our radio show. LAME and Liveice convert the audio output to MP3-encoded specifications so anyone with xmms or Winamp can decode our signal. Broadcasting MP3-encoded material at this time does not require any licensing, however it is anticipated that in the year 2001 royalties will be collected by the agency holding the patent. You can obtain more information regarding these issues at www.mp3licensing.com. If the company that holds the patent imposes royalties, we plan to move to a different encode, decode schema. Ogg Vorbis is a patent and royalty-free compressed audio formatter that we anticipate moving our broadcast server to in the near future. Ogg Vorbis is available at www.xiph.org. Also, the MP3 licensing does not cover issues regarding broadcasting copyrighted material to a public audience so if you plan to run an Internet radio station, be certain you have permission to broadcast anything for which you do not hold the copyright.
We use standard hardware because we found quickly that obscure components introduce unnecessary delays in the setup process. The rest of this article details the setup of each component in our internet radio station. We also describe any problems that we encountered along the way. Please understand that there are a million ways to create an internet radio station, and the choices we made were not due to any alliance with any vendor—we simply made it work in the following mannner.
Figure 1 gives an overview of our network that starts when it gets our voices to an MP3 player. We speak into microphones, the microphones convert our voice to analog and the mixer condenses the stream into the line-in on the encoder client that runs Liveice. Liveice picks up the stream and uses LAME to convert our voice from analog to digital. Liveice then sends our digitized stream out onto the Internet to our defined broadcast server that runs Icecast. Icecast takes the incoming stream and broadcasts it onto the Internet at both the destination and port www.opensourceradio.com:8000. Once it is on the Internet, any decoding client, such as an MP3 player, can pick up the stream and decode our digital stream to audio output.
We wanted to succeed right away so we acquired a domain, static IP and a server with open ports. A static IP and domain are not necessary, but by making everything static we don't need to inform our listener base every time our ISP changes our IP. We also connected our server to the Internet via a T1. This gives us the bandwidth to provide high-quality broadcasting. Our broadcast server, Linux3 and our static IP are provided by www.doitwebcorp.com. The server is a standard networked PC running Red Hat Linux 6.2.
We started by downloading the Icecast server software from www.icecast.org. We chose to use version 1.3.7 because it was considered the most stable release available at the time. We used the default installation that locates the binaries in /usr/local/icecast. The configuration of the Icecast server is very simple, you only need to change one file. The icecast.conf file is very informative. The sections we changed allow the encoder client to send streaming audio to the broadcast server that will be serving to the Internet. Our server is set up with the IP address 188.8.131.52 with the registered domain of www.opensourceradio.com. If you compare the default icecast.conf file to our example icecast.conf file, you will see the fields that we changed. This is only a portion of the icecast.conf file, as it is a very large file.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
3 hours 44 min ago
- BASH script to log IPs on public web server
8 hours 11 min ago
11 hours 47 min ago
- Reply to comment | Linux Journal
12 hours 19 min ago
- All the articles you talked
14 hours 43 min ago
- All the articles you talked
14 hours 46 min ago
- All the articles you talked
14 hours 47 min ago
19 hours 12 min ago
- Keeping track of IP address
21 hours 3 min ago
- Roll your own dynamic dns
1 day 2 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?