In order to broadcast an audio stream of the federal scout convention in germany, I searched the web for the building blocks to bring an audio source to the web and make the listening as easy as possible.
The broadcasting stack for my usecase consists of these parts:
- A source client that converts and streams the digitized audio to a relay server
- A streaming media server that relays the stream to the clients
- A web player which makes the stream visible to the listeners on the web
The streaming server
Lets jump right to the middle of the stack, as the decision for the relay server software narrows the choices for the other building blocks. There is a variety of free streaming server projects available: the list of streaming servers on wikipedia provides a list of open source as well as comercial solutions.
I decided on icecast2, an open source streaming server maintained by the Xiph.org Foundation. The server can be configured via an easy understandable XML file to run multiple streams, called mountpoints in parallel.
On an ubuntu server, icecast2 can be easily installed via apt-get install icecast2, the configuration file can then be found on /etc/icecast2/icecast.xml where you at least have to set the source-password which the source clients use to connect to the server. The mountpount /stream is defined implicitly.
A stream definition can be defined as follows:
<mount type="normal">
<mount-name>/live</mount-name>
<fallback-mount>/Fallback/Muzak.mp3</fallback-mount>
<fallback-override>1</fallback-override>
<stream-name>Live Broadcasting</stream-name>
<stream-description>Listen to the live briadcast.</stream-description>
<stream-url>http://cast.your.domainc</stream-url>
<max-listeners>200</max-listeners>
<public>0</public>
<type>audio/mpeg</type>
<dump-file>/var/streamDump/live/Recording-%d_%m_%Y-%H%M_%S.mp3</dump-file>
</mount>
Two cool features configured in the example are worth to be mentioned.
- Fallbacks: <fallback-mount> defines a mount position to fallback to when the current mountpoint has no streaming source connected. The mount-point can be either the url of another stream or the path to file within ``/usr/share/icecast2/web``. If a listener connects while the source is not streaming, the listener will receive audio from the fallback. As soon as a source connects, all connected listeners are automatically reassigned to the original mountpoint. Some client software although seem to have problems with shifting between different audio formats. Therefore, you should take care, that your fallback stream / file has the same format and encoding (bit- / sampling rate) like the normal stream.
- Recording: <dump-file> enabled the local recording of the stream. This can be helpful to just keep a remote backup or to provide the recordings for listening after the live show ended.
Some words on scalability
Icecast2 seems to be very resource-friendly and performant. A performance test with 300 simulated listeners using gatling with icecast running on a rather old Intel Xeon with 1,8 GHz and 4 GB of RAM showed only a very low CPU usage. Im sure the bandwidth available through your network interface is always the limiting factor.
The source client
Took me a while to find a simple and free streaming source client for Mac Os X. Most of the available clients are designed for a dj or radio station use case, where you mostly stream music from the local disk and rarely use a microphone for voice over. Mixxx is a really cool open source dj software for that purpose.
For my use case, I needed a solution that simply takes the input of an audio interface and sends the encoded audio to the streaming server. In case you can bear the ancient user interface style, then "butt - broadcast using this tool" is the perfect tool for that purpose. In four small configuration tabs, you define the audio source, the encoding parameters and the streaming server settings and your done. You can also record the audio while streaming.
The main screen shows everything you need, like details and the current status of the stream and also the audio input displayed on a level meter.
Sometimes the audio routing behavior on Mac OS seems a little bit strange. If you have some advanced audio routing wishes - for example if you just want to monitor the recorded audio on your Laptops speakers - I recommend the free audio tools LineIn and Soundflower from rogueamoeba.
Web audio player
The stream produced by icecast can be consumed by any streaming media player including desktop or mobile browsers without any further software by just following the URL. For a better presentation of the stream and the recordings, I use jPlayer, a tiny open source media player for both audio and video. jPlayer uses the HTML 5 elements if available in the browser or an adobe flash fallback otherwise. It is also totally customizable and skinnable from an one button audio player to a full video player with playlists.
What is missing, is a possibility to have statistics of the listeners over time. Here seems piwik with a custom source of the icecast access.log a suitable tool. If you have any questions or improvements, do not hesitate to leave a comment.