The purpose of this article is to help you in creating a reliable and free one-way audio link over the Internet.The primary use case is to enable low-cost transmission of radio program from radio station premises to a remote broadcasting tower.
The method explained here is suitable for other one-way transmission needs as well, but due to long latency it cannot be used for two-way conversations (use e.g. Skype instead).
Streaming live audio signal from one computer to another can be accomplished even with old low-cost computer hardware and free open source software, which makes the setup very affordable and enables interesting use cases.
Abstract.
There are many different needs for sending an audible signal from one location to another. The technology that works in one use case may not work well in another. We can divide the applications into two main categories:
The applications in the first category are aimed for enabling conversations over long distances. Telephone calls and teleconferences are perfect examples. Within this category the sound quality is not the top priority, but low latency can be considered a must. Both closed and open source software solutions exist, the most well-known being Skype.
The applications in the second category are aimed for broadcasting an audio signal from a single source to a larger audience, which in general does not need to be able to communicate back to the source (i.e. the audience listens only). Within this category the sound quality is an important enabler for long listening periods, whereas long latency can be usually tolerated well. Both closed and open source software solutions exist, for example Shoutcast and Icecast.
The setup described in this article is intended to be a one-way pipe for high quality live audio signal. Therefore, these instructions are likely useful in use cases that fall to the second category.
Introduction.
In this article, audio streaming over the Internet network is applied to a radio station that needs to send its program to a remote transmitter tower. This new setup will replace current expensive ISDN connection with a lower cost version as follows: An old PC will be located in the radio tower’s cabin and used as a server computer that receives live audio stream over an Internet connection, and plays it back. The audio signal from the server PC’s sound card is routed to a radio transmitter device and further to an antenna. The program source comes from a client computer that sends the audio signal to the server over the Internet. It can be for example a laptop equipped with a microphone and a CD/MP3 player software.
As Internet radio is nowadays a rather well established concept, it is not a surprise that mature software solutions exist for setting up own Internet radio station. One of them is Icecast, an open source server software for streaming multimedia. In this article, Icecast is used in the server computer as a connection point where audio content can be streamed to from other locations. However, instead of sharing the audio stream to hundreds of listeners via the Internet – as is usually done with Icecast – here it is played back immediately on the server computer’s own sound card and further routed as an analog audio signal. In order to play the audio with the server computer, also an Icecast compatible client software needs to be running on the server, here Ogg123 is used as a player. This way, whatever audio content is streamed to the server, it can be immediately and automatically played back to the audience. Ices2 and Edcast are examples of applications that can be used as a the streaming source, running on the client computer. Both support Ogg Vorbis and MP3 encoding, among others. There are in fact quite many packing algorithms. Ogg Vorbis is used in this article because it is both free and provides very good audio quality.
This kind of setup makes transmitting radio program from various local events simple: one can setup the equipment at the radio tower so that the devices can be turned on remotely e.g. with an SMS from a mobile phone, then open a connection to the server computer from a laptop over the Internet, and begin broadcasting real radio program to the listeners from wherever one happens to be.
What is needed.
The main building blocks of the system are these:
1. An old PC that can be dedicated to act as an audio link server computer in the receiving end
2. Ubuntu Linux 8.04 Server as an operating system for the server computer
3. Icecast 2 as a streaming software backend for the server computer
4. Ogg123 as an audio stream player for the server computer
5. Ogg Vorbis audio encoder and decoder for audio data packing (client side) and unpacking (server side)
6. A Linux or a Windows computer to act as the client computer in the sending end
7. Ices2 (Linux) or Edcast (Windows) as audio streaming application for the client computer
Naturally also broadband network connection is needed for both the server and the client computer. Various audio equipment, such as microphones, mixers, CD players, headphones and monitors might be necessary, depending on your use case.
1. Selecting the server computer
One should begin with selecting and acquiring a PC that will be used as the backend server for the Internet audio link. This computer does not need to be a new, fancy dream machine with all the latest and greatest – on the contrary; it should be a simple, decent and reliable work horse that can be dedicated to this one task. What we are looking for is a typical home or office PC made somewhere 1997 or later. You can probably find one for free either from your own garage, or by asking your friends and relatives. I got a suitable computer from my sister’s husband, who was going to throw it away. As an example of adequate machine, see the specifications of that computer below.
* Intel Pentium MMX 166 MHz processor
* 64 MB memory
* 2 GB hard drive
* ATI Rage II+ display adapter
* Creative SB Live sound card
* CD-ROM drive
2. Preparing the server computer hardware
The first task is to check that the computer is adequate for the purpose we are going to use it. The requirements are somewhat dependent on the chosen Linux version. Since we are using Ubuntu 8.04 Server in this article, I think the computer should have at least 120 MHz Pentium processor (tested to work), 64 megabytes of RAM (tested to work) and a gigabyte or more of hard drive space (Ubuntu installation alone will require ~400 megabytes). It must have a sound card and a network card. Note that keyboard, display and CD-ROM drive are useful only during the initial setup phase, as the computer can be managed remotely over the network connection later on. Mouse is not needed at all, nor is the horse power for running a graphical desktop environment.
If the computer is to be placed into a remote location where it cannot be easily accessed after the initial setup is done, I think it is reasonable to clean it now while it is available. I also recommend taking notes and photographs of the components, especially how they are connected, as this information may turn invaluable later on when you are doing some remote management over an Internet connection. For example, the preparation tasks might include these:
* Turn power off from the rear power source switch, remove all external cords from the computer and open the computer case.
* Remove dust e.g. with a vacuum cleaner (be careful), then make sure that all parts and cables are firmly attached inside and that there are no loose parts.
* Organize cables etc. so that the air can flow through the case with ease and check that all fans work properly by temporarily attaching power cord and turning the computer on for a short period (then turn it off and remove the power cord again).
* Take a few photographs of the interior (in case you need to check something later or give guidance to someone else from a remote location) – try to get pictures where one can see some details of the components and how they are attached, for example to which IDE ports hard drive and CD-ROM drives are connected to and whether there is room for upgrades (empty slots on motherboard and case).
* Make a list of all parts and their models (motherboard, processor, memory…), that will help during installation and later if you need to solve problems.
* Put all the pieces back together, then plug in the keyboard, display and power cords for setup phase.
As an example, this is my list of the components:
* Motherboard: Titanium P51430TX/IIB, Intel + Winbond chipset, 4xPCI, 4xISA, 4xSIMM, 2xDIMM
* Processor: Intel Pentium MMX 166 MHz Socket 7
* Memory: 4x 16MB (long) SIMM
* VGA: ATI Rage II+, chipset 3D Rage II+ DVD
* Sound: Creative SB Live, model CT-4750
* Hard drive: Seagate Medalist ST32122A, 4092 cyl, 2111 MB, 16 heads, 63 sectors (IDE1 master)
* Floppy: 3.5″ Teac FDD, model FD-235HF
* CD-drive: Toshiba 24x CD-ROM, model XM-6102B (IDE2 master)
* Case: Wings (ATX)
* PSU: Seventeam ST-200HRK (ATX)
Note: In case you want to start the computer remotely e.g. via SMS, you’ll need a device that can receive SMS messages and turn power on/off in its outputs (where you should connect your computer’s power cord). In addition, you probably need to modify the computer a little. Some PCs can be made to start automatically when they begin to receive power simply by configuring this behavior in the BIOS. Others need a small hardware modification. Old computers based on AT design have on/off type power switch, which you can simply leave “on” – it’s as simple as that. However, modern ATX form factor computers use a momentary power switch, which cannot be used like that. This can be solved by connecting two certain wires together in the big cord that comes from the PSU and is connected to the motherboard (google for instructions on which pins to connect). I had to go with the last option. For convenience, I even added a switch into the back of the computer so that I can enable/disable auto start feature with ease.
3. Configuring the BIOS
It is quite likely that there isn’t that much to tune in the BIOS. However, it may be a good idea to load “optimized default” settings just for sure, especially if you got the computer from someone else. Then check that all settings seems to be ok and the computer is working fine.
One thing to note is that since the computer may not have a keyboard attached to it in the remote location, you should check that it is not required during boot procedure. Typically there is a setting called “Halt on”, and a proper setting value might be for example “All but keyboard”.
Also, you might want to try to optimize the boot time to be as short as possible by removing some checks from the boot operation sequence. However, in general you should not try to tweak the computer to run as fast as possible e.g. via overclocking the processor or tweaking memory timings. There’s no use for this kind of tricks in our application, but they can make the computer hardware unreliable, which we definitely want to avoid.
To prepare for the next phase, you should check the BIOS settings for the boot media. Make sure that the computer can be booted from a CD. After installing the operating system, change the boot sequence so that it only starts from hard drive (C-drive). This will take a few seconds off from boot time.
4. Installing the operating system
If you don’t already have Ubuntu 8.04 Server CD, create it now (see instructions from Ubuntu website if you don’t know how to make it). When you’re done, put the CD into the server computer’s CD drive and turn the computer on. After a while, Ubuntu start menu should appear on your display.
* Select your language (I prefer English although it is not my native language).
* If you’ve just burned the CD, you should test it in order to avoid problems later. Select “Check CD for defects”. When you’re done, reboot from the CD.
* If you’re not sure that the computer hardware is OK, you should at least run the memory test. Select “Test memory”. When you’re done, reboot from CD.
* To begin installation, select “Install Ubuntu Server”.
* Choose your language (e.g. English)
* Choose country/territory/area (e.g. Finland)
* Choose keyboard layout (e.g. Finland). Wait a moment.
* Next the installer will try to detect your network card and configure it. This may either work or fail, but it doesn’t really matter at this point – you’ll probably need to configure it manually later anyway, as the server needs a static IP address and the installer waits for dynamic IP address to be assigned by a DHCP server in your network. In case the network detection fails, you are given a possibility to configure it manually. At this point, I chose not to (“Do not configure the network at this time).
* However, you should still give a hostname (the name of the computer), which is asked next. I wrote “RadioServer1″. Wait a moment.
* The hard drive needs to be partitioned next. I chose “Guided – use entire disk”. The wizard suggested to divide my 2 GB hard drive to one big 1.9 GB partition with ext3 filesystem, and another small 150 MB swap partition. This is fine, so I accepted it by choosing “Finish partitioning and write changes to disk”.
* Next, a summary of changes was shown together with a confirmation request. Ok’ed that.
* Wait a while – this time somewhat longer, up to several hours if your computer is low on memory.
* Write user name (full name and account name). Write password (use a good one!).
* Choose services to install. From the options presented in the list, you only need OpenSSH server for remote management. If you plan to use a web browser for controlling the server, I recommend not to install the full LAMP setup for this purpose; you can install a much more lightweight solution in a later phase. This is important especially if you are low on resources (old computer).
* Wait. When the installation is complete, the computer will eject the Ubuntu CD and ask your permission to reboot. Do it.
5. Booting the first time
After installing the operating system and booting the computer the first time, you should read the text that is printed to screen. Watch out for errors. For example, my computer printed this line:
ACPI: Bios age (1997) fails cutoff (2000), acpi=force is required to enable ACPI
It is not critical to have ACPI, and my computer does not support it. I got rid of the note as follows:
* When boot procedure is finished, login prompt is shown. Log in with your user account name and password that were created during operating system installation.
* Type sudo nano /boot/grub/menu.lst to begin editing boot options.
* Look for a commented line #defoptions=quiet splash and append to the end of the same line acpi=off apm=on. New kernels that will be installed along with future updates will get these boot options. Note: do not uncomment the line; these are used by debian update-grub script.
* Then look for the first line that begins kernel /boot/vmlinuz … and append to the end of the same line acpi=off apm=on
* You might want to consider removing quiet splash options from both places mentioned above. This way you get more information on screen while booting, which is usually a good thing for a server computer.
* Save CTRL + O and exit CTRL+X.
* Reboot the computer by writing to console sudo reboot
After successfully logging in, I checked a few basic things:
* Write dmesg | more to read system messages and look for errors. I did not have anything alerting, just some minor nags.
* Write df -h to see how much free space is left on the hard drive after installing Ubuntu Linux. In my computer it took about 400 MB and thus left me with 1.4 GB of free space. That is more than enough for software required for an audio link setup.
6. Setting up networking
One of the first things after Ubuntu installation is setting up networking. I assume you have some kind of router box that has a DHCP service for providing automatic IP address and configuration for clients. I performed the following steps:
* Write lspci to console in order to list all found PCI devices. I could see that my network card, which is equipped with Realtek RTL-8139 chipset, was included in the list, so the computer found it. I also remember that when I printed system messages with dmesg | more in previous step I could see that network card driver was successfully loaded.
* Write sudo nano /etc/network/interfaces to edit network devices. Probably only the loopback devices is listed, so you should add eth0 first as follows:
auto eth0
iface eth0 inet dhcp
* Write it out CTRL+O and exit CTRL+X.
* Connect network cable, if not already connected.
* Write sudo ifup eth0. You should see that system is starting networking with eth0 interface and trying get IP address, gateway and DNS server addresses from DHCP.
* You can check out the success. Write ifconfig to see details about network interfaces. You should see eth0 with proper IP address and some RX and TX packets already sent/received. Next, write cat /etc/resolv.conf, you should see a printout of (likely two) domain name server IPs. Finally, write route to see that default gateway has been setup properly.
* You should test the network connection. For example, write ping www.google.com to see that a) your computer can resolve domain name www.google.com to an IP address, and b) your computer has access to Internet and it can send and receive data. If you have troubles, try writing sudo ifdown eth0 and then sudo ifup eth0 or reboot the computer. If this does not help, google for help on setting up network in Ubuntu Linux.
* At this point I got a minor problem. The computer updated its clock from the Internet time servers, and whenever I tried to use sudo for managing the computer, it replied sudo: timestamp too far in the future: [...time...]. I got rid of this problem simply by writing sudo -K
* When you get the network working, remember that it needs to be configured for server use. Write again sudo nano /etc/network/interfaces. Comment the line iface eth0 inet dhcp by adding # character, i.e. the line becomes #iface eth0 inet dhcp and then add manual IP configuration with following new lines:
iface eth0 inet static
address 192.168.1.11
netmask 255.255.255.0
gateway 192.168.1.1
* Of course, the addresses need to be adapted according to your own network.
* Write out CTRL+O and exit CTRL+X.
* To really apply the new settings, write sudo ifdown eth0, then sudo ifup eth0, and check that IP address has changed with ifconfig.
* You can use another computer in the same network to check that your server can be accessed. Use for example ping 192.168.1.11 (or whatever is your server’s IP address that you just set) to see that it replies to requests properly.
* When you move the computer to the actual remote location, you need to setup networking again! Change it back to DHCP first to get DNS server IPs and to check that networking in general in that location is ok. Then switch back to the manual configuration, and setup a proper IP address and gateway.
* You probably also need to edit your network router box’s settings, for example open the necessary ports and route request from the Internet to the server computer’s IP address.
* Note: another alternative to manual configuration is to continue using automatic configuration, and apply the permanent IP address by editing the router’s settings (IP – MAC address binding in the DHCP table). Depending on the network setup in the remote usage location, it might be even possible to configure the router box in advance and then simply move both the server and the router box to the remote location, without any on-site configuration.
7. Updating your Ubuntu Linux installation
Now that you have a working network connection, it’s time to update the operating system. Don’t leave this to a later phase, do it now!
* Write sudo apt-get update to update package source list first.
* Write sudo apt-get upgrade to upgrade your installation to newest available software packages (this can take a while and even require a reboot).
By the way, the reason for selecting Ubuntu 8.04 Server for this project is that it was a) latest release when writing this guide, b) popular Linux distribution, c) already familiar to me, and d) provides updates for 5 YEARS, starting from April 2008 – which is nice for a remote server computer that you do not wish to install again soon.
8. Setting up remote management
Since you now have a server computer in your network, set up with SSH server software, it is possible to now continue either locally (as done so far) or remotely. At least
you should try that the remote management works. Check it like this:
* Write ps aux | grep ssh to see list of processes with ssh in the name. You should see a line that says something like /usr/sbin/sshd on the right. It means that SSH server (daemon) is started.
* Go to another computer in the same network and write ssh [your server's IP address] -l [your user account name], e.g. ssh 192.168.1.11 -l trk. After accepting RSA key you should be logged in to the server. If you open the SSH port and forward the request properly in your network router, your server computer can be now safely and securely managed by you from wherever you can connect to the Internet!
* Note: if you only have Windows boxes, you can’t just type ssh … to the DOS box. Instead, you need an application for SSH. I recommend the free Putty.
9. Adding user accounts
You might wish to create more user accounts to the server, for example for remote management by multiple persons. This is easy in Ubuntu Linux:
* Write sudo useradd -d /home/newuser -m newuser, but replace newuser with proper user account name you wish to create.
* Write sudo passwd newuser (again, replace newuser) to set a password.
* If you trust admin (sudo) rights to the new user, write sudo adduser newuser admin (once again, replace newuser).
* You probably want that the shell works similar to the root account (bash). Write sudo nano /etc/passwd, then look for the name of the account you created (probably in the end of the file), and change the end of that line from /bin/sh to /bin/bash and then log in again with that account.
10. Setting up Icecast 2 server software
Installing Icecast is simple: write sudo apt-get install icecast2
After installation is finished, it needs to be configured. Write cat /etc/default/icecast2. This will print the defaults for Icecast, including path to server configuration file, and user id and group that are used for running the Icecast server. By default Icecast is disabled. Before enabling it, we must configure it correctly.
Write sudo nano /etc/icecast2/icecast.xml to begin editing configuration file. Then edit the settings as follows (only changes to be made are listed, section is named in parentheses to help locating the correct setting from the file):
(limits)
clients = 20
(authentication)
source-password = [your chosen password]
relay-password = [your chosen password]
admin-user = [your chosen admin username]
admin-password = [your chosen password]
hostname = RadioServer
<!-- My radio channel configuration -->
<mount>
<mount-name>/radioprogram.ogg</mount-name>
<public>0</public>
<on-connect>/home/radio/radioprogram-start.sh</on-connect>
<on-disconnect>/home/radio/radioprogram-end.sh</on-disconnect>
</mount>
<fileserver>0</fileserver>
(logging)
<loglevel>2</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
(security)
<changeowner>
<user>icecast2>/user>
<group>icecast</group>
</changeowner>
Write out CTRL+O, and exit CTRL+X.
Now that we have configured Icecast, we can enable it. Write sudo nano /etc/default/icecast2. Change the line ENABLE=false to ENABLE=true. Write out CTRL+O, and exit CTRL+X.
Now you can try to start Icecast server. Command /etc/init.d/icecast2 will print usage guide. Now go ahead and start it as follows: sudo /etc/init.d/icecast2 start. Note that you can also start it manually and specify the configuration file as follows: sudo icecast2 -c /etc/icecast2/icecast.xml. Warning: for simplicity, these commands use sudo in this testing phase. However, in the long term you should not use sudo to run the server, but a separate user and group with properly set access rights.
If you don’t use sudo here you might get an error message saying I/O warning : failed to load external entity /etc/icecast2/icecast.xml, which means that your user account does not have rights to access the configuration file. Simply write sudo adduser newuser icecast (replace newuser with your username), log out, log in, and try again.
In a similar manner, if you get an error message nagging about log files (Permission denied), write sudo chmod 775 /var/log/icecast2/ to give your user account right to write to the log file directory. You may need to delete existing log files, if there is any! Then try again.
An error message saying Unable to set gid to [number] (Operation not permitted) means that in /etc/default/icecast2 file, user id and group id are set and we need admin rights to enable the group id for the process to be started, thus sudo needs to be used to make this effective.
If nothing seems to happen after writing the start command, then the server started. Press CTRL+C to get back to the prompt, and write sudo /etc/init.d/icecast2 stop to stop the server.
Write icecast2 -b -c /etc/icecast2/icecast.xml to make the Icecast server running in the background. This can be checked by writing ps aux | grep icecast2, then you should see two lines, the first one for the actual icecast2 process and the second one for the grep command you just wrote.
Now you can also try to reboot the computer, to check that Icecast2 server will start automatically. Write sudo reboot now, and observe the screen when the computer boots. You should see a few lines related to Icecast2, e.g. Starting icecast2 … When the computer has started, log in and check again with ps aux | grep icecast2 that the process is in fact running.
You can also check that there are no errors in the error log. Write cat /var/log/icecast2/error.log and check it out.
Make sure that admin interface works. Open a web browser from another computer in the same network, and type http://192.168.1.11:8000/ (change the IP address and port number to the ones that match your server setup). You should see a basic Icecast2 web interface in your browser. Now click the link Administration, and write the admin user name and password that you specified earlier into the Icecast2 configuration file. The admin web interface should load.
11. Setting up sound support and a player for incoming audio data
Ubuntu server installation does not include support for sound in vanilla installation. This is can be well understood, as many server setups simply don’t need any sound capabilities. However, in the audio link application the server must have sound, since we want that the server computer plays back the audio stream that it receives from the Internet via Icecast.
Begin by writing lspci to check that your sound card is recognized in Ubuntu Linux. For example, in my computer this created a list of devices and one of the printed lines tells that sound card is recognized: 00:0c.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev o2).
Next, check that the drivers are loaded by writing lsmod | grep snd. In my computer, various modules were listed (11 lines, in fact).
Write sudo apt-get install alsa-utils. This will install sound support and some utilities, including volume control.
Write alsamixer to start newly installed volume control application. All volume levels are probably turned down and muted, so in order to hear anything, you need to crank up the volumes (use arrow keys) and unmute them (press ‘m’). Turn up at least Master and PCM lines, and check that they are not muted. Exit by pressing the ESC key. Then write sudo alsactl store to save the settings.
Next we will install a sound player application. It must be able to co-operate with Icecast2 software. You can find a list of media players that support Icecast2 streams from http://www.icecast.org/3rdparty.php. Since we are using an old computer without graphical X environment, command line based applications like ogg123 and mpg321 are natural choices. Install ogg123 and related packages by writing sudo apt-get install vorbis-tools. You can test ogg123 for example as follows: ogg123 http://www.vorbis.com/music/Epoq-Lepidoptera.ogg. You should see that ogg123 begins to stream a file from the Internet and hear it being played back. If you can’t hear anything but otherwise it seems to work, then go back to alsamixer and check that the correct channels are turned up and not muted. Then try again.
Install mpg321 and related packages by writing sudo apt-get install mpg321. You can test mpg321 for example as follows: mpg321 http://wahiduddin.net/troubleshooting/testing.mp3. You should see that mpg321 begins to stream a file from the Internet and hear it being played back. If you can’t hear anything but otherwise it seems to
work, then go back to alsamixer and check that you have correct channels turned up and unmuted. Then try again.
Now you should have sound working, and players that can stream ogg and mp3 files from the Internet – or, from your locally installed icecast software, as we plan to do.
12. Testing audio streaming with another computer as a source client
In this section we will finally create a working audio link. First we need to install a source client software to another computer in the same network. A list of compatible source clients can be found from http://www.icecast.org/3rdparty.php. For example, if you use Windows computer, install e.g. Edcast. If you use Linux computer, then install e.g. Ices. Here we use console-based Ices with Ubuntu 8.04 Desktop Linux computer as a client.
Go to the other computer in the same network, open console and write sudo apt-get install ices2. This will install a source client that is compatible with Icecast2 server and can stream audio with Ogg Vorbis lossy packing algorithm. Continue working with the client computer as follows.
Go to your home directory by writing cd ~. Then create a test directory mkdir icetest, and go there cd icetest. Copy example ices2 source configuration files from ices2 documentation folder to your test dir: cp /usr/share/doc/ices2/examples/ices-alsa.xml . (live capture) and cp /usr/share/doc/ices2/examples/ices-playlist.xml . (playlist).
You probably want to try playlist first, as it is a bit easier to get working. Edit the configuration as follows by writing nano ices-playlist.xml, i.e. change the following fields (use your own server’s IP address, port and password).
<param name="file">/home/[YOUR USER ID]/icetest/playlist.txt</param>
<hostname>192.168.1.11</hostaname>
<port>8000</port>
<password>password</password>
<mount>/test.ogg</mount>
<yp>0</yp>
Write out CTRL+O, and exit CTRL+X.
Open a web browser, go to http://www.vorbis.com/music/ and download some .ogg sample files. Save them to ~/icetest directory.
Create playlist from sample files: find ~/icetest -iname “*.ogg” > playlist.txt. Start source by writing ices2 ~/icetest/ices-playlist.xml. Open web browser and go to http://192.168.1.11:8000 and check Server status page, where you should be able to see that the server computer now receives data from the source computer – i.e. you should see that a new mount point has been created, called /test.ogg. In addition, if you go to the Administration page, you should see that there is now one source client and detailed information about the mount point.
Go to your server computer, open console, and use ogg123 (that you set up in the previous step) to begin listening the audio stream: ogg123 http://localhost:8000/test.ogg. You should quickly begin to hear the sound being played back. It comes from the other computer – you have now created a working audio link!
However, you probably do not plan to stick to playlists only – thus, we need to setup live capturing as well. Stop both audio player (ogg123) and source client (ices) by giving them CTRL+C. Then, edit the configuration file again as follows by writing nano ices-alsa.xml on the source client computer, i.e. change the following fields:
<hostname>192.168.1.11</hostaname>
<port>8000</port>
<password>password</password>
<mount>/test.ogg</mount>
<yp>0</yp>
Start source by writing ices2 ~/icetest/ices-alsa.xml. You can then test the source via web browser and ogg123 just like you did with playlist source. However, it is somewhat likely that in the web browser everything seems to be fine at first glance, but you still don’t hear anything. In the web browser, when you click the link Admin home and observe the /test.ogg mount point’s details, you might notice that total_bytes_read field grows rather slowly, especially when compared to previous test with playlist stream (refresh the page a few times to see it change). If you experience something like this, then open your sound mixer in the source client computer, and try to turn volumes and switches on until you find the right configuration. This is easier to do e.g. using Audacity application, by turning input monitoring on and observing when the volume bars begin to move. Then exit audacity to release sound capturing channel, and start ices again. Streaming from live source should now work!
13. Tuning the bandwith
The sound quality at default settings is rather poor (downsampled to single 22 kHz channel). You probably wan’t to adjust the setting for a) higher sound quality, and b) more reliable stream (ie. no drop-outs). Case a) is handled mainly in the source client’s settings, and case b) in the player’s settings.
Go to source client computer and edit ices settings: nano ices-alsa.xml, then change the settings as follows:
<encode>
<quality>1</quality<
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<downmix>0</downmix>
<resample>
<in-rate>44100</in-rate>
<out-rate>44100</out-rate>
</resample>
Write out CTRL+O, and exit CTRL+X. The stream contains now much higher quality sound, when you restart it: ices2 ~/icetest/ices-alsa.xml.
Go to server computer and start sound playback with longer buffering: ogg123 -b 256 -p 50 http://localhost:8000/test.ogg. You should now hear good quality, reliable sound playback. However, note that there is more than 20 second delay between the original sound and the playback. This is mainly due to long buffers. In my test, when I set -b and -p to 0 i.e. input buffer is set to minimum size (only 8 kb), there is still 9 second startup delay (and I get occasional drop-outs). If I re-configure ices-alsa.xml and upgrade quality from 1 to 8, then the delay is less than 3 seconds. This happens because higher quality means more bits per second and thus fixed size buffers will get flushed more quickly. However, drop-outs occur more easily.
Now you might wonder how fast Internet connection is needed in practise. The server needs to be able to download in average at least the amount of data that the encoded stream requires, whereas the client needs to be able to upload that fast. Usually download speed is faster than the upload speed, which you must take into account: in general, the client needs a faster Internet connection than the server.
Therefore, what is expected from the broadband Internet connection depends on a) parameters used for the encoder (sound quality), and b) the direction of the data flow. If the connection has problems in keeping the speed of the data stream constant then faster nominal connection is necessary, so we can add c) the quality of the connection.
As a result, if you use e.g. 64 kbit/s stream in the encoder, then 64 kbit/s theoretical upload speed will not be fast enough! TCP/IP stack adds many additional bits to the stream, which also need to be transferred. Moreover, there will always be some hiccups in the transfer (i.e. for a short moment no data is transferred at all). In order to tolerate these, additional bandwidth is required so that buffering can handle the hiccups without any audible trace. To be on the safe side, double the speed of the encoder: 64 kbit/s encoder stream should work fine on 128 kbit/s upload link.
I have successfully sent data (client side) using a mobile phone in EDGE (EGPRS) network, but plain GRPS is not fast enough. EDGE should be about 4 times faster than GPRS and reach above 200 kbit/s in practise. This goes well with the theory above, EDGE should be fast enough but GPRS not.
It is also possible to chain multiple radio networks in serial. In one test, I used a laptop as a program source. It was connected to my N95 mobile phone via Bluetooth, which connected to the Internet via EDGE. The server computer was connected to the Internet via 450 MHz wireless broadband, and played back the audio signal. Then an FM radio transmitter was used to send the audio signal as FM radio program, which was finally received and played back by an FM radio receiver. All the equipment was located in the same room, but the signal travelled through 4 different radio networks and hundreds of kilometers! The sound quality was still very good.
Note that this kind of setup allows great flexibility: both the program source and the transmission tower can be wirelessly connected to the Internet and thus easily moved from one location to another. The program source can also be battery powered (at least for a while), e.g. a laptop and a mobile phone. With a suitable Icecast compatible client software, the program source could be in fact be no more than a mobile phone – one could play sound files from the phone’s memory, or use the built-in microphone or e.g. a Bluetooth microphone for live programs! Although that would be very cool, I’m not aware of any such client software for mobile phones – yet. That would be an interesting hobby project to make one.
14. Auto-starting playback upon source client connection
Although the audio link is already working, there is still some tricks to be done. For example, to make the server better automated and more convenient to use, we can auto-start playback when a source client connects to it with a simple script. This way we can control the playback from the client, i.e. from only one point in the chain. Here an example of such a script is presented.
First we will add icecast2 user to audio group, so that the player can be started with a script run by icecast2 user: sudo usermod -a -G audio icecast2.
Next, create a directory for automation scripts: sudo mkdir /home/radio and go to that directory: cd /home/radio. Then create a new script for auto-starting playback: sudo nano radioprogram-start.sh and write the following content:
#!/bin/bash
# Script to be run when radio program begins
# Notify all users of beginning radio transmission.
wall < /home/radio/radioprogram-start_message.txt
# Remove potential program end flag, if any.
FLAGFILE=/tmp/program_end.flag
if [ -e $FLAGFILE ]
then
rm -f $FLAGFILE
fi
# Start playing radio program.
/usr/bin/ogg123 -b 512 -p 100 http://127.0.0.1:8000/radioprogram.ogg &
# End of File
Save CTRL+O and exit CTRL+X.
Change permissions so that the script can be run by you and all users in the icecast group: sudo chown icecast2:icecast radioprogram-start.sh and sudo chmod 754 radioprogram-start.sh.
The script will print a short message to all users that have currently logged in, to notify of beginning of a radio transmission. Write a text file, which contains a message to be sent: sudo nano radioprogram-start_message.txt and type e.g. the following content:
RADIO TRANSMISSION BEGINS!!!
Save CTRL+O and exit CTRL+X.
Change permissions so that the message can be read by you and all users in the icecast group: sudo chown icecast2:icecast radioprogram-start_message.sh and sudo chmod 754 radioprogram-start_message.sh.
The script will also delete a flag file, if found from /tmp directory. This will be explained in the following chapter.
Playback will be initiated in the background, with 512 kb buffer size and 100% pre-buffering, using Icecast2 mount point named radioprogram.ogg.
In order to make Icecast2 server run the script when client opens a connection to the server (i.e. begins radio transmission), begin editing the Icecast2 server’s settings as follows: sudo nano /etc/icecast2/icecast.xml, then create/add the following section. Pay attention to <on-connect> line!
<!-- Radio program configuration -->
<mount>
<mount-name>/radioprogram.ogg</mount-name>
<public>0</public>
<on-connect>/home/radio/radioprogram-start.sh</on-connect>
<on-disconnect>/home/radio/radioprogram-end.sh</on-disconnect>
</mount>
Save CTRL+O and exit CTRL+X.
In order to test this, you need to go to the client computer and check that the mount point matches /radioprogram.ogg in your ices configuration file. Then you need to restart Icecast2 server software on the server computer so that the changed configuration file will be read: /etc/init.d/icecast2 stop and sudo icecast2 -b -c /etc/icecast2/icecast.xml. Finally, from the client computer, start sending content to the server: ices2 ~/icetest/ices-alsa.xml. The player should automatically start (in the background), and a notification be printed on the screen.
In case of troubles, write cat /var/log/icecast2/error.log and check it out. Also note that it is possible that the player was in fact started OK, but there is only a problem in writing the notification text on the screen and due to long buffering delay, you don’t here anything (yet). You can test that by writing ps aux and observing if a process with name /usr/bin/ogg123 is running (meaning that the script worked), or just wait a while until player’s buffer is filled and audio playback begins. For further testing, you can kill the player with sudo kill [PID], where [PID] is the ID of the player process (you can see that from ps aux output).
You have now probably figured out one problem in the script: it will try to create a new player instance every time the client makes a connection. That’s not good in case the connection breaks and you need to reconnect. We will handle this with another script and a flag file, see next chapter.
15. Shutting down server after source client disconnection
When it is time to end the radio transmission, we will likely want to shutdown the server computer in the radio transmission site. If you have set up a power on/off system with e.g. SMS from a mobile phone, this can be easily performed. However, one shouldn’t just cut the power off from any computer, these devices need to be prepared for shutdown. For more convenient use, this can be configured to happen automatically after the source client disconnects from the server (i.e. ends sending radio program content).
It is possible that the connection breaks by accident for a short moment, and in this case the server should not automatically shut itself down. We can solve this dilemma with a time delay: after the connection gets broken, a timer will be started. When the timer triggers, we will check if the connection has been opened again, or not. Then we can decide whether to go for shutdown, or to continue radio transmission. In practise, a flag file can be created for marking a potential shutdown, to be deleted when a connection returns. If the connection doesn’t return in time, the flag file will still be there when the shutdown timer triggers, and we know that we can proceed to shutdown. Necessary code for deleting an existing flag file was already written to on-connection script in the previous chapter, now will do the rest with the on-disconnection script.
Shutting down the server computer requires admin rights. Since Icecast2 server software will initiate the shutdown procedure, it needs to have the right to do that. Here we allow it to run (only) the shutdown script as follows: sudo visudo -f /etc/sudoers, then add icecast2 ALL=NOPASSWD: /sbin/shutdown, save and exit.
Now we can create a script that will be run when the client disconnects: cd /home/radio, then sudo nano radioprogram-end.sh and write the following content:
#!/bin/bash
# Script to be run when radio program ends.
# Write potential program end flag.
FLAGFILE=/tmp/program_end.flag
touch $FLAGFILE
# Wait a while (3 minutes) to see if the program begins again.
sleep 180
# Check if program has started again.
if [ -e $FLAGFILE ]
then
# Notify all users of ending radio transmission.
wall < /home/radio/radioprogram-end_message.txt
# Shutdown computer.
sudo shutdown -hP now > /var/log/icecast2/shutdown.log 2>&1
fi
# End of File
Save CTRL+O and exit CTRL+X.
Change permissions so that the script can be run by you and all users in the icecast group: sudo chown icecast2:icecast radioprogram-end.sh and sudo chmod 754 radioprogram-end.sh.
The script will print a short message to all users that have currently logged in, to notify of ending of a radio transmission. Write a text file, which contains a message to be sent: sudo nano radioprogram-end_message.txt and type e.g. the following content:
RADIO TRANSMISSION ENDS!!!
Save CTRL+O and exit CTRL+X.
Change permissions so that the message can be read by you and all users in the icecast group: sudo chown icecast2:icecast radioprogram-start_end.sh and sudo chmod 754 radioprogram-end_message.sh.
In order to make Icecast2 server run the script when client closes a connection to the server (i.e. ends radio transmission), edit the Icecast2 server’s settings as follows: sudo nano /etc/icecast2/icecast.xml, then create/add the following section. Pay attention to <on-disconnect> line!
<!-- Radio program configuration -->
<mount>
<mount-name>/radioprogram.ogg</mount-name>
<public>0</public>
<on-connect>/home/radio/radioprogram-start.sh</on-connect>
<on-disconnect>/home/radio/radioprogram-end.sh</on-disconnect>
</mount>
Save CTRL+O and exit CTRL+X.
In order to test this, you need to go to the client computer and check that the mount point matches /radioprogram.ogg in your ices configuration file. Then you need to restart Icecast2 server software on the server computer so that the changed configuration file will be read: /etc/init.d/icecast2 stop and sudo icecast2 -b -c /etc/icecast2/icecast.xml. Finally, from the client computer, start sending content to the server: ices2 ~/icetest/ices-alsa.xml. The player should automatically start (in the background), and a notification be printed on the screen. Then you can give CTRL-C to it, and the player on the server computer should stop as well. After the time delay, the computer should shutdown, unless you start sending content again. During the time delay, you should see the flag file already in place in /tmp folder and the sleep process running with ps aux command.
In case of troubles, write cat /var/log/icecast2/error.log and check it out. It is possible that the player stops after its internal buffer becomes empty, and the computer will shut itself down after the time delay. For easier testing, you don’t want the computer to shutdown all the time, so comment out that line from the script and re-enable it when you’re done.
16. Firewall
Since the server computer needs to be reachable from the Internet, some openness is required. However, you should deny all traffic exept what is absolutely necessary. This is achieved with a firewall, which can be either a separate hardware device, built-in to a network router, or implemented with software in the server computer itself. Here an example configuration is presented for using the sofware firewall included in the Ubuntu Linux distribution.
The firewall software is called iptables. It can be configured very precisely, but is known to be somewhat complex to set up. You can check current firewall rules by writing sudo iptables -L. By default, it should allow all traffic. Next we will configure it for audio link use by adding a few new rules. Note that the order of the following commands is very important.
* Allow loopback device: sudo iptables -I INPUT 1 -i lo -j ACCEPT
* Allow established sessions: sudo iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
* Allow incoming traffic to SSH port for remote administration: sudo iptables -A INPUT -p tcp –dport ssh -j ACCEPT
* Allow icecast sources to send radio program, and web administration: sudo iptables -A INPUT -p tcp –dport 8000 -j ACCEPT
* Block all other incoming traffic: sudo iptables -A INPUT -i eth0 -j DROP
Check the rules by writing sudo iptables -L, you should see these rules printed out:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:8000
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Save configuration now: sudo iptables-save, then save the firewall rules into a file: sudo sh -c “iptables-save > /etc/iptables.rules”
Finally we will enable the firewall rules by automatically loading them from the saved file when the network is brought up. Begin editing network configuration: sudo nano /etc/network/interfaces, then make the following adjustments:
auto eth0
iface eth0 inet static
address 192.168.1.11
netmask 255.255.255.0
gateway 192.168.1.1
pre-up iptables-restore < /etc/iptables.rules
Save CTRL+O and exit CTRL+X.
Now the server computer should only allow access to SSH server and Icecast server, blocking all other connection attemps outside.
17. Dynamic DNS
In case the broadband operator uses dynamic IP address, it can be difficult to know from which IP address the server can be accessed as it can change often. This problem can be solved by upgrading to static IP address (usually expensive), or by using a free Internet service called dynamic DNS. The service allows reserving a subdomain (xxxx.something.com) and updating your current IP address to the service, so that the traffic to your reserved subdomain can be forwarded to your current IP address. Thus you should be able to always access the server via the subdomain.
There are multiple providers of dynamis DNS service. Here we use DynDns.com, which is probably the most famous of them. Go to www.dyndns.com with a web browser, create an account and store the information you get:
* username: XXXX
* password: XXXX
* domain: XXXX
The server computer needs a few adjustments to publish its IP address that it gets from broadband operator’s DHCP server to DynDns servers.
First install ipcheck tool: sudo apt-get install ipcheck.
Then continue as follows to create a place for IP publishing script: sudo su, cd /root, mkdir ipcheck, cd ipcheck. Then store the account information into a file: nano dyndns_account, write only one line: [dyndns username] [dyndns password] [dyndns subdomain], save CTRL+O and exit CTRL+X. Change file permissions: chmod o-r dyndns_account.
Create the IP publisher script by writing nano dyndns_update.sh and add the following content:
#!/bin/sh
cd /root/ipcheck/
if [ -f ipcheck.dat ]; then
/usr/sbin/ipcheck -l -r checkip.dyndns.org:8245 --acctfile dyndns_account
else
/usr/sbin/ipcheck --makedat -l -r checkip.dyndns.org:8245 --acctfile dyndns_account
fi
Save CTRL+O and exit CTRL+X. Change permissions: chmod +x dyndns_update.sh.
Type exit to exit from superuser login.
Finally we need to edit one of the system startup scripts to run our new IP publishing script: sudo nano /etc/rc.local. Add/change the file to look like this:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
test -x /root/ipcheck/dyndns_update.sh && /root/ipcheck/dyndns_update.sh
exit 0
Save CTRL+O and exit CTRL+X.
After rebooting the server, you should be able to use http://[YOURSUBDOMAIN].dyndns.org:8000/ to access the server – provided that it is running, connected to Internet and properly routed/firewall to be accessible from the Internet.
18. Automatic disk scans on boot
As the server may need to be rebooted during live radio programme if something goes terribly wrong, it would be VERY annoying if this happened to be the 30th time the computer is booted and a long lasting disk scan would start. Or, if the computer is used after long period of time, it would also trigger the scanning. As we actually can live without this feature, we’ll just turn it off as follows: begin editing file system configuration table sudo nano /etc/fstab, then change the last column from 1 to 0 for main partition, save with CTRL+O and exit CTRL+X.
19. Cleaning up
Some reminders for things to be done before taking the server to production use:
Check:
* Icecast log level – what do you actually need to get logged. Also check that processes aren’t filling the hard disk with continuously growing log files (logs should be configured rorating).
* Activate shutdown feature again in the shutdown script, in case you commented it out for testing
* Check all passwords; they should not use any default values or otherwise bad passwords!
* Make sure you have documented the basics of the server setup, and stored passwords to a safe place. If everything goes fine, the computer will be almost forgotten and soon nobody remembers anything about its setup – so do document!
Test:
* Server start time (how many seconds after turning the power on you can start sending audio signal to the server)
* Playback start time (how many seconds after audio signal has started to arrive will the player begin to play it back)
* Playback stop time (how many seconds after audio signal has stopped to arrive will the player stop to play it back)
* Server stop time (how many seconds after the audio signal has stopped to arrive the server has shut itself down)
* That no hiccups occur with configured encoder settings
* That the speed of the broadband connection is fast enough for used encoder settings
* That network configuration is adjusted to the actual production network, and it works
* That remote administration can be performed via web interface and SSH
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 comments:
Post a Comment