After I came up with the idea of creating a radio station from an audio stream of http://twitter.com/public_timeline, I started working on a solution to make it work. First thing I need was a free hosting service. I didn't really expect to find anything, but lo and behold I found two immediately. After some consideration, I decided to go with http://www.listen2myradio.com. They support Shoutcast streaming and their site is ad supported with an option for a premium account.
Now with a host in mind and a format, I now had to figure out how to make my scripts work with a Shoutcast source client. I went ahead and used the Nullsoft sc_trans binary since I was familiar with it. My first thought of playing the audio from my server and have sc_trans pick it up via /dev/dsp failed miserably. The sc_trans binary is older than dirt at this point, and on Ubuntu Server 8.04.2 sc_trans would lock up when /dev/sdp was set as the source. Then I got another idea. I decided to add a step in the script that would convert the wav to mp3 using LAME. This added a marginal processing time of of approximatly 2 secs on average per RSS pulled. The total processing time now was up to about four to six seconds. Throwing Shoutcast into the mix did change things though. With the bluetooth system, once a wav file had reached the end, it would disconnect audio from the headset and then repeat the cycle. The Shoutcast source streamer is going to stream the audio based on a playlist. In the playlist configuration, it is not designed for a live feed and I can't capture /dev/dsp. Since this is Linux we are talking about it ended up not really being a problem. The aggregation and audio converstion script will ouput an mp3 with a single filename. sc_trans can be playing that file and if overwritten, the new audio immediatly begins playing. It's a hack for sure, but it doesn't sound bad. The aggregation script had to be changed to run every minute and sleep since there would be nothing to make it pause in the course of the script.
Once everything was in place I tested it. It worked as well as expected. I let it run for a while to see how long it would stay up. The answer was about a day or two. Reasons varied from sc_trans having a segmentation fault to full system lockup. Occasionally sc_trans would be fine. The aggregation and conversion script would be running, but the stream from the net would be silent. One reboot everyday or two would be a short term solution till a better system was devised, but that was a problem. I have a virtual machine on that server that hosts some services for an expiremental IPV6 overlay network. Some of the services in that virutal machine have to be brought up manually. This made doing this a chore. My answer was to setup a speprate VM for the radio station broadcasting software. Now all that is done in a Ubuntu 9.04 server running in VirtualBox. Cron was rebooting the VirtualBox server 4 times a day until a few days ago when I set it for 12 am and 12 pm. It takes approxiamly 2 minutes from reboot to audio. Occasionally I am getting unknown Shoutcast server disconnects, but after reading logs I think it is my stream host shutting down it's end due to an error caused at the host. The station's twitter page is here: http://twitter.com/timelineradio The bit.ly link will take you to the audio streams page.
In "Audio based interfaces for Twitter Part 3" I will cover the mechanisms for advertising the service so that it is picked up in the public timeline and my attempt to use Google Voice transcription as a speech to text conversion tool.
Now with a host in mind and a format, I now had to figure out how to make my scripts work with a Shoutcast source client. I went ahead and used the Nullsoft sc_trans binary since I was familiar with it. My first thought of playing the audio from my server and have sc_trans pick it up via /dev/dsp failed miserably. The sc_trans binary is older than dirt at this point, and on Ubuntu Server 8.04.2 sc_trans would lock up when /dev/sdp was set as the source. Then I got another idea. I decided to add a step in the script that would convert the wav to mp3 using LAME. This added a marginal processing time of of approximatly 2 secs on average per RSS pulled. The total processing time now was up to about four to six seconds. Throwing Shoutcast into the mix did change things though. With the bluetooth system, once a wav file had reached the end, it would disconnect audio from the headset and then repeat the cycle. The Shoutcast source streamer is going to stream the audio based on a playlist. In the playlist configuration, it is not designed for a live feed and I can't capture /dev/dsp. Since this is Linux we are talking about it ended up not really being a problem. The aggregation and audio converstion script will ouput an mp3 with a single filename. sc_trans can be playing that file and if overwritten, the new audio immediatly begins playing. It's a hack for sure, but it doesn't sound bad. The aggregation script had to be changed to run every minute and sleep since there would be nothing to make it pause in the course of the script.
Once everything was in place I tested it. It worked as well as expected. I let it run for a while to see how long it would stay up. The answer was about a day or two. Reasons varied from sc_trans having a segmentation fault to full system lockup. Occasionally sc_trans would be fine. The aggregation and conversion script would be running, but the stream from the net would be silent. One reboot everyday or two would be a short term solution till a better system was devised, but that was a problem. I have a virtual machine on that server that hosts some services for an expiremental IPV6 overlay network. Some of the services in that virutal machine have to be brought up manually. This made doing this a chore. My answer was to setup a speprate VM for the radio station broadcasting software. Now all that is done in a Ubuntu 9.04 server running in VirtualBox. Cron was rebooting the VirtualBox server 4 times a day until a few days ago when I set it for 12 am and 12 pm. It takes approxiamly 2 minutes from reboot to audio. Occasionally I am getting unknown Shoutcast server disconnects, but after reading logs I think it is my stream host shutting down it's end due to an error caused at the host. The station's twitter page is here: http://twitter.com/timelineradio The bit.ly link will take you to the audio streams page.
In "Audio based interfaces for Twitter Part 3" I will cover the mechanisms for advertising the service so that it is picked up in the public timeline and my attempt to use Google Voice transcription as a speech to text conversion tool.
No comments:
Post a Comment