Streaming Audio with Ices and Icecast
My encoding computer is also running Mandriva. Because this machine is running only at 233MHz with 64MB of RAM, I decided to do a minimal install and leave off the window manager. Ices is also available from the contrib repository. So once again, typing urpmi ices is all it took to install Ices. However, you can download the latest releases from the Ices Web site (see Resources). Make sure you use the 2.0 series if you want to use Ogg. It also requires that libshout is installed. Once you have that, you can extract the archive and run ./configure; make; make install to get everything installed.
The Ices configuration file is also an XML file. It is usually stored in /etc/ices.conf.
The beginning of the configuration file has some settings that dictate how Ices runs. It can be helpful to change these during the initial setup, so that Ices runs in the foreground and sends messages to the console. These messages can be very helpful in debugging problems on initial setup. Once everything is set up and running, make sure Ices runs in the background and logs messages to a file:
<background>1</background> <logpath>/var/log/ices</logpath> <logfile>ices.log</logfile> <loglevel>3</loglevel> <consolelog>0</consolelog>
The rest of the file is under the stream section. This is where you configure settings specific to this particular audio stream. Within the stream section, the metadata section is where you specify information about the stream. This information will be displayed on the Icecast Web page:
<metadata> <name>W0ZWY 146.895 MHz</name> <genre>Live</genre> <description>Live feed of the W0ZWY repeater</description> </metadata>
The input section is the place to define where the audio actually comes from. There are many possibilities, including options for playlists and scripts. Because I want to encode live audio, I used the oss module. Don't be alarmed if your system uses the ALSA sound system instead of OSS. ALSA has OSS compatibility, so this module works with both ALSA and OSS. Use the device parameter to specify the sound device from which to get data. On most systems it will be /dev/dsp. The rate parameter specifies the sample rate of the data in hertz. Most devices use 44100. Use the channels parameter to specify the number of channels available for capture. For most devices this will be 2 (stereo):
<input> <module>oss</module> <param name='device'>/dev/dsp</param> <param name='rate'>44100</param> <param name='channels'>2</param> </input>
The instance section allows you to specify the number of instances of this stream. You might have more than one instance if you want to send the stream to more than one server, or if you want to have different versions of the same stream at different bitrates. For my system, I want only one instance.
The first part of the instance section is where you specify the streaming server information. The hostname tells Ices where to send the data. The port and password must match the values you specified in the Icecast configuration file. The mount option specifies what the name of the stream will be called.
The encode section specifies how the audio will be encoded. The easy way to do it is to set the sample rate and channels to match the input section above. But, I didn't need that much quality for my stream. So, I used the downmix and resample sections to tell Ices to resample the audio to 11127Hz and downmix it to 1 channel (mono). There are two options you can use to adjust the final bitrate of the stream: quality and nominal-bitrate. Notice that I commented out nominal-bitrate and set quality to 2:
<instance> <hostname>192.168.1.1</hostname> <port>8000</port> <password>hackme</password> <mount>/146.895.ogg</mount> <encode> <quality>2</quality> <!--nominal-bitrate>32000</nominal-bitrate--> <samplerate>11127</samplerate> <channels>1</channels> </encode> <downmix>1</downmix> <resample> <in-rate>44100</in-rate> <out-rate>11127</out-rate> </resample> </instance>
Once the configuration file is all ready, make sure that Ices has permission to access the audio device through /dev/dsp. Mandriva creates an audio group, which owns the /dev/dsp file. It also creates an ices user and group when ices is installed. I simply added ices as a member of the audio group in the /etc/groups file by editing the audio group:
Finally, you can start Ices by running the init script: /etc/init.d/ices start. If there are any errors during startup, look in the log files to debug them. It also can be helpful to examine the Icecast log files on your streaming computer to debug problems.
Once everything is up and running, you can access the Icecast status page on the port you specified in the configuration file. Figure 3 shows an example of an Icecast status page. Clicking on Click to Listen launches your audio player.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide