Gentoo Logo
Gentoo Logo Side

Streaming Radio With SHOUTcast


1. Setting up SHOUTcast Server

Installing the files 

The SHOUTcast Server can be found in media-sound/SHOUTcast-server-bin. You can install it with the following command:

Code Listing 1.1: Emerging SHOUTcast

# emerge shoutcast-server-bin

The SHOUTcast Server will now be installed. The next step is configuring your new SHOUTcast Server.

Configuring SHOUTcast Server 

Now that SHOUTcast Server is installed, it must be configured. The configuration file can be found in /etc/shoutcast/sc_serv.conf. Let's begin with the configuration. Make sure you are root, and open the configuration file with your favorite editor. I choose vi for this example. Now I'll bring up the file with vi:

Code Listing 1.2: Opening the configuration file

# vi /etc/shoutcast/sc_serv.conf

This will bring up the SHOUTcast Server configuration file for viewing. From there you will see the configuration file and the different options that you can set. Let's take a look on how to setup these particular options.

Mandatory Options 

Code Listing 1.3: Setting the user limit

; MaxUser.  The maximum number of simultaneous listeners allowed.
; Compute a reasonable value for your available upstream bandwidth (i.e. if
; you have 256kbps upload DSL, and want to broadcast at 24kbps, you would
; choose 256kbps/24kbps=10 maximum listeners.)  Setting this value higher
; only wastes RAM and screws up your broadcast when more people connect
; than you can support.

This is where the maximum number of users is set. As the caption states, it is foolish to setup 100 users on a 256kbs upload (This is what I have set, as my upload is about that). If you're running SHOUTcast Server to serve a LAN, you can probably set this MUCH higher (to the 100 mentioned easily). Please remember to not abuse whatever bandwith you are using though. Bandwith is a high cost to ISP's and service providers, and some will cut your account, fine you high costs to makeup, or both.

Code Listing 1.4: Setting the password

; Password.  While SHOUTcast never asks a listener for a password, a
; password is required to broadcast through the server, and to perform
; administration via the web interface to this server.  This server should
; consist of only letters and numbers, and is the same server your broadcaster
; will need to enter in the SHOUTcast Source Plug-in for Winamp.  THIS VALUE

Here is where you setup the password. The password itself is clear text. For security purposes, I STRONGLY recommend that you don't use passwords that are used to access critical system components or other sensitive information. Make this as random as possible, with a combination of letters and numbers. This password will be what SHOUTcast Trans (or any other content provider) will use to connect and provide streaming content.

Code Listing 1.5: Setting up your listening port

; PortBase. This is the port number your server will run on.  The
; value, and the value + 1 must be available.  If you get a fatal error when
; the DNAS is setting up a socket on startup, make sure nothing else on the
; machine is running on the same port (telnet localhost portnumber -- if you
; get connection refused then you're clear to use that port).  Ports less than 1024
; may require root privledges on *nix machines.  The default port is 8000.

This value sets up what port users will connect to on your SHOUTcast Server. The default is 8000, as it is what most mp3 server capable programs will default to (xmms, winamp, etc.). As it states, if you wish to use a port less than 1024, you will need to be root. However, I strongly urge against using any port lower than 1024 for your SHOUTcast Server.

Code Listing 1.6: Setting up logging

; LogFile: file to use for logging. Can be '/dev/null' or 'none'
; or empty to turn off logging. The default is ./sc_serv.log
; on *nix systems or sc_serv_dir\sc_serv.log on win32.
; Note: on win32 systems if no path is specified the location is
; in the same dir as the executable, on *nix systems it is in the
; current directory.

This sets the location of the SHOUTcast server log file. The ebuild has it set to /dev/null, so you will need to change it in order to get a real log. I have it setup in the basic /var/log location. You can have it log to wherever you need.

Code Listing 1.7: Enabling real time stats

; RealTime displays a status line that is updated every second
; with the latest information on the current stream (*nix and win32
; console systems only)

This displays information on the current song to stdout every second. This is disabled by the ebuild so that the SHOUTcast daemon can run as silently as possible. Set this to 1 if you want these updates each second. However, I recommend you use the status page instead.

Code Listing 1.8: Enabling real time logging

; ScreenLog controls whether logging is printed to the screen or not
; on *nix and win32 console systems. It is useful to disable this when
; running servers in background without their own terminals. Default is 1

This is disabled by default in the ebuild to, once again, run the daemon as silently as possible. This will log any events (connects, disconnects, etc) to stdout as they happen in realtime. However, because the log file does the same thing, I recommend using it instead.

Code Listing 1.9: Setting the last number of songs displayed

; ShowLastSongs specifies how many songs to list in the /played.html
; page.  The default is 10.  Acceptable entries are 1 to 20.

Just as it states, this value will set how many of the most recently played /played.html will display. If you put more than 20, you should probably consider more coffee.

Code Listing 1.10: Setting up filesystem modification logging

; TchLog decides whether or not the DNAS logfile should track yp
; directory touches.  Adds and removes still appear regardless of
; this setting.
; Default is yes
; TchLog=yes

This setting enables or disables logging for directory modifications by the DNAS (Distributed Network Audio Server), or SHOUTcast for short. Recommended for those who wish to have the most secure logging possible. Basic home/casual users probably don't need this.

Code Listing 1.11: Enabling http request logging

; WebLog decides whether or not hits to http:// on this DNAS will
; be logged.  Most people leave this off because the DSP plug-in
; uses http:// calls to update titles and get the listener count,
; which takes up a lot of log space eventually.  If you want to
; see people making hits on your admin.cgi or index pages, turn
; this back on.  Note that this setting does NOT affect XML stats
; counters for hits to http:// pages.
; Default is no.
; WebLog=no

This specifies whether or not you want to log hits to the http server that SHOUTcast provides. Once again, recommended for those who wish the most secure logging possible, but not recommended for home/casual users.

Code Listing 1.12: Enabling W3C Logging

; W3CEnable turns on W3C Logging.  W3C logs contain httpd-like accounts
; of every track played for every listener, including byte counts those listeners
; took.  This data can be parsed with tools like Analog and WebTrends, or given
; to third parties like Arbitron and Measurecast for their reporting systems.
; Default is Yes (enabled).

; W3CLog describes the name of the logfile for W3C logging.  Default logfile is
; sc_w3c.log, in the same directory wherever the DNAS gets started from.

The first option enables W3C logging. This type of logging is easily parsable by the recommended programs listed. Highly recommended for those who wish to have the most in depth statistics possible. The second option specifies where to store the W3C log. This is set to /dev/null by the ebuild.

Network Configuration 

Code Listing 1.13: Setting the source IP

; SrcIP, the interface to listen for source connections on (or to make relay
; connections on if relaying). Can and usually will be ANY or
; (Making it will keep other machines from being able to
; broadcast using your SHOUTcast Server )

The SrcIP variable sets what IP streaming content is coming from. This can be another server (relaying), localhost (regular), or any other IP that your interface supports. Setting to localhost prevents any other server from using your SHOUTcast Server as a broadcast source. The default is ANY and will cause your SHOUTcast Server to source from any IP. Security wise, it is better to set this to something specific.

Code Listing 1.14: Setting the destination IP

; DestIP, IP to listen for clients on (and to contact
; can and usually will be be ANY. If your machine has multiple IP addresses,
; set this to the one you want it to be accessed by.

This determines which IP on your interface you will allow users to connect to. This can be localhost (if you're anti-social and wish only to stream to yourself), a private IP ( for hosting to a local lan), or your external IP (409.204.249.201 for streaming to a WAN, but not a LAN). In most cases, you can reach your own stream by using instead of what is listed here. ANY lets your SHOUTcast Server bind to all IP addresses on all avaliable interfaces.

Code Listing 1.15: Setting proxy/ port

; Yport, port to connect to on. For people behind caching
; webproxies, change this to the alternate port (666 is what it might be,
; check if you have problems). Otherwise, leave this at 80.
; We're actively working on re-opening port 666, but as of release the only
; working port is port 80.

This has 2 functions. First is the port to connect to with. is nullsoft's page for public servers so users know where to listen in on. Users can search for your station from this page. The secondary use is for web proxies. Set this to the port you use for proxy connects, and set DestIP to your proxy for streaming.

Code Listing 1.16: Setting up reverse DNS

; NameLookups.  Specify 1 to perform reverse DNS on connections.
; This option may increase the time it takes to connect to your
; server if your DNS server is slow.  Default is 0 (off).

This options specifies whether or not you want to preform reverse DNS lookups on clients. This would take their host and give you an IP. Use this for logging purposes to create a more detailed report.

Code Listing 1.17: Setting up relaying

; RelayPort and RelayServer specify that you want to be a relay server.
; Relay servers act as clients to another server, and rebroadcast.
; Set RelayPort to 0, RelayServer to empty, or just leave these commented
; out to disable relay mode.
; RelayPort=8000
; RelayServer=

This specifies that you are acting as a relay server. Relay servers are often used to take a low bandwith connection that can only stream to one client, and use its own higher bandwith to serve to more clients. RelayPort specifies the port and IP address of the SHOUTcast Server you wish to relay for. Comment this out if you don't plan on using your server as a relay.

Server Configuration 

Code Listing 1.18: Setting the admin password

; AdminPassword.  This password (if specified) changes the
; behavior of Password to be a broadcast-only password, and
; limits HTTP administration tasks to the password specified
; here.  The broadcaster, with the password above, can still
; log in and view connected users, but only the AdminPassword
; will grant the right to kick, ban, and specify reserve hosts.
; The default is undefined (Password allows control for both
; source and admin)
; AdminPassword=adminpass

Setting this will create a broadcaster and administrator. The broadcaster can log in with Password, and view connections. However, should the person want to kick/ban/administer the server, they must have the Admin password. This option creates more pecific roles for your server. This is recommended for instances where the system administrator is not the same person as the broadcaster.

Code Listing 1.19: Setting up auto user disconnect

; AutoDumpUsers controls whether listeners are disconnected if the source
; stream disconnects. The default is 0.

This specifies whether or not users are kicked out if the stream disconnects for any reason. This is set to 0, so that clients will either timeout themselves, or keep trying to buffer a stream. Use this if you expect short interruptions at any time.

Code Listing 1.20: Setting up the source timeout

; AutoDumpSourceTime specifies how long, in seconds, the source stream is
; allowed to be idle before the server disconnects it. 0 will let the source
; stream idle indefinately before disconnecting. The default is 30.

This specifies when the SHOUTcast Server should give up waiting for a source (mainly a relay server) to stream content from. 30-60 should be reasonable enough values for this.

Code Listing 1.21: Setting up the content directory

; ContentDir specifies the directory location on disk of where to stream
; on-demand content from.  Subdirectories are supported as of DNAS 1.8.2.
; Default is ./content/, meaning a directory named content in the same directory
; as where sc_serv was invoked from.

The ContentDir specifies where to put on demand content. For example, if you wish to stream an announcement to employees, you could use this for that purpose. The SHOUTcast Server ebuild sets this to /opt/SHOUTcast/content for you. To use this, put an mp3 in the content directory, then point your browser to[port]/content/mp3name.pls. SHOUTcast Server will autmatically create a streaming media compatible playlist for the mp3, and stream it on demand. Use this as an alternative to SHOUTcast Trans for streaming media source.

Code Listing 1.22: Setting up an intro file

; IntroFile can specify a mp3 file that will be streamed to listeners right
; when they connect before they hear the live stream.
; Note that the intro file MUST be the same samplerate/channels as the
; live stream in order for this to work properly. Although bitrate CAN
; vary, you can use '%d' to specify the bitrate in the filename
; (i.e. C:\intro%d.mp3 would be C:\intro64.mp3 if you are casting at 64kbps).
; The default is no IntroFile
; IntroFile=c:\intro%d.mp3

This allows you to configure an intro file. Everytime users connect, they'll hear this file played. As it states, the stream bitrate and the intro song bitrate must match, or else things will break. You can, however, put something such as intro128.mp3 and intro64.mp3, and it will play intro128.mp3 to users connecting to a 128kbps stream, and intro64 users connecting at 64kbps.

Code Listing 1.23: Setting up a back file

; BackupFile can specify a mp3 file that will be streamed to listeners over
; and over again when the source stream disconnects. AutoDumpUsers must be
; 0 to use this feature. When the source stream reconnects, the listeners
; are rejoined into the live broadcast.
; Note that the backup file MUST be the same samplerate/channels as the
; live stream in order for this to work properly. Although bitrate CAN
; vary, you can use '%d' to specify the bitrate in the filename
; (i.e. C:\backup%d.mp3 would be C:\backup32.mp3 if you are casting at 32kbps).
; The default is no BackupFile
; BackupFile=C:\intro%d.mp3

This is the same as above, but will be played when the stream source ends, instead of when users disconnect. This will only work if AutoDumpUsers is set to 0.

Code Listing 1.24: Setting up a title format

; TitleFormat specifies a format string for what title is sent to the listener.
; For example, a string of 'Justin Radio' forces the title 'Justin Radio' even
; when the source changes the title. You can use up to one '%s' in the string
; which lets you contain the title from the source. For example, if your
; TitleFormat is 'Justin Radio: %s', and the source plug-in's title is
; 'Billy plays the blues', then the net title is
; 'Justin Radio: Billy plays the blues'. Note: only works on non-relay servers.
; The default is no format string.
TitleFormat=Chris Gentoo Beats: %s

This sets up a non-variable title for your Shoutcast server. Use this if your source stream differs from your SHOUTcast Server's name. This will NOT work with relay servers.

Code Listing 1.25: Setting up a URL format

; URLFormat specifies a format string for what url is sent to the listener.
; Behaves like TitleFormat (see above).
; The default is no format string.
; URLFormat=

This is the same as TitleFormat except that the URL listed above is used instead of the source stream's URL.

Code Listing 1.26: Setting up the public status of a source stream

; PublicServer can be always, never, or default (the default, heh)
; Any setting other than default will override the public status
; of the source plug-in or of a SHOUTcast Server that is being relayed.

This specifies whether or not you want to be listed as a public server even if your relay server/source plugin is listed as such.

Code Listing 1.27: Allowing relaying

; AllowRelay determines whether or not other SHOUTcast Servers will be
; permitted to relay this server.  The default is Yes.

AllowRelay determines of other servers are allowed to relay your content. If you don't think you'll ever relay at all, set this to No.

Code Listing 1.28: Allowing relays to publically display the source

; AllowPublicRelay, when set to No, will tell any relaying servers not
; to list the server in the SHOUTcast directory (non-public), provided
; the relaying server's Public flag is set to default.  The default is
; Yes.

AllowPublicRelay specifies whether or not you wish to be listed in the SHOUTcastpublic directory of the server you're relaying to is already listed. Note that PublicServer can override this setting.

Code Listing 1.29: Setting MetaInterval

; MetaInterval specifies how often, in bytes, metadata sent.
; You should really leave this at the default of 32768, but the option is
; provided anyway.

Just leave this as is.

Access Configuration 

Code Listing 1.30: Setting the max listner time

; ListenerTimer is a value in minutes of maximum permitted time for
; a connected listener.  If someone is connected for longer than this
; amount of time, in minutes, they are disconnected.  When undefined, 
; there is no limit defined.  Default is undefined.
; ListenerTimer=600

I'm not to sure why you'd need this one. Basically, if a user is on for too many minutes, disconnect them. Only thing I can think of is to kick idlers off, or people you think should be doing other things than listening to your stream. Value is measured in minutes.

Code Listing 1.31: Setting up the ban file

; BanFile is the text file sc_serv reads and writes to/from
; for the list of clients prohibited to connect to this
; server.  It's automatically generated via the web
; interface.
; BanFile=sc_serv.ban

This is the filename for the list of clients that are banned from your server. The default is sc_serv.ban, but you can use whatever name you so desire with this setting.

Code Listing 1.32: Setting the Rip list

; RipFile is the text file sc_serv reads and writes to/from
; for the list of client IPs which are *ALWAYS* permitted
; to connect to this server (useful for relay servers).
; This file is automatically generated via the web
; interface.  Note that if your server is FULL, and someone
; from a Reserved IP connects, the DNAS will force the person
; listening for the longest time off to make room for the new
; connection.

As grim as it sounds, Rip actually stands for "Reserved IP". Use this for your friends or other people you consider more important than random users. If you are currently streaming to the max number of users possible, and one of your rip members tries to get on, it will kick the longest listening person from the server to get them on.

Code Listing 1.33: Setup if Rip only users can access your server

; RipOnly, when set to Yes, will only allow IP addresses listed in the Reserved
; IP list to connect and relay.  All other connections for listening will be denied.
; This is really only useful for servers whose sole purpose is to provide the
; primary feed to all public relays.  Setting this value to Yes also forces the
; server into Private mode, since listing this server in the directory would
; be pointless.  Default is No.
; RipOnly=No

This allows for only Rip members to connect to your SHOUTcast Server. You can either use this for private radio streams, or to make it so that only certain relays will be able to access your stream.

Mass Configuration 

Code Listing 1.34: Setting Unique variables

; Unique: assigns a variable name for use in any config item which points to a
; file.  Useful for servers running lots of SHOUTcast Servers that have similar
; configuration parameters, excepting logfile names, banfile names, etc.  Any
; parameter that takes a pathname can include the character $, which will
; substitute $ for the variable assigned here.  Keep in mind that the unique
; variable can only be used after it is defined, so don't try to use a unique
; variable substitution in a path before you define it.  For example, you
; could set:
; Unique=my_server
; and then define Log=/usr/local/SHOUTcast/$.log in an included configuration
; file.  Default is Unique=$, so that by default any file with $ in the name
; won't substitute anything at all.

Basically, if you're running lots of SHOUTcast Servers, it would be a dire pain to change all the log/ban/etc. files to something unique for every configuration. Instead, you can set Unique to something, and $ will be replaced with whatever Unique is set to. For example, if one file had Unique=Jazz and another had Unique=Rock, then Log=/var/log/$.log would produce /var/log/Jazz.log on one config file and /var/log/Rock.log on another config file. Much easier when dealing with multiple SHOUTcast Servers with similiar configurations.

Code Listing 1.35: Setting up common configure variables

; Include: instructs the sc_serv to read from the named configuration file,
; *at the point of insertion of the Include statement*, and process as though
; the included file was part of itself.  Note that all configuration parameters
; in the DNAS config file are processed first to last, so if an item is defined
; twice in a configuration, the last item to process will be the one that takes
; effect.  For this reason, it's usually a good idea to use the Includes first
; in a config file.
; example:
; Include=/usr/local/SHOUTcast/common.conf
; Default is not applicable.

If you're running multiple SHOUTcast Servers and wish to utilize similar configuration variables without setting them all for each configuration file, you can set this to point to a file that contains settings that are similiar between multiple configurations.

Optimization Configuration 

Code Listing 1.36: Setup number of CPU's utilized

; CpuCount is used to explicitly limit the DNAS to dominating a finite
; amount of processors in multiprocessor systems.  By default,
; SHOUTcast creates one thread for every processor it detects in the
; host system, and assigns listeners equally across all the threads.
; In the event SHOUTcast doesn't correctly determine the number of
; CPUs in your host, or if you for whatever reason want to force
; the DNAS to not use other processors, you can say so here.
; Default behavior is to use as many processors as the DNAS detects on
; your system.
; CpuCount=1

On multiple CPU systems, use this setting to force the SHOUTcast Server to utilize CpuCount # of processors. The default to assign one thread to each processor, and have listeners across all the threads. If you set this lower than your total processor count, this will leave processors free to do other things.

Code Listing 1.37: Setup data submission gap

; Sleep defines the granularity of the client threads for sending data.
; DNAS 1.7.0, per client thread, will send up to 1,024 bytes of data
; per socket (or less depending on the window available), and then
; sleep for the provided duration before repeating the whole process.
; Note that making this value smaller will vastly increase CPU usage on
; your machine.  Increasing reduces CPU, but increasing this value too far
; will cause skips.  The value which seems most optimal for 128kbps
; streaming is 833 (833 microseconds per client poll) on our test labs.
; We wouldn't recommend setting it any lower than 100, or any higher than
; 1,024.  If you have a slower machine, set this number lower to fix
; skips.
; Default value is 833.
; Sleep=833

The SHOUTcast Server will use the sleep value in determining the gap between sending data. The higher the value, the longer the gap, the lower the value, the shorter the gap and the more CPU usage SHOUTcast Server will take up. On slower systems, as it states, you might want to lower this so that the SHOUTcast Servers sends data more and more frequently to users. Best to leave as is.

Code Listing 1.38: Setup XML output

; CleanXML strips some whitespace and linefeeds from XML output which
; confuses some (poorly written) XML parsers.  If you get XML rendering errors,
; try turning this on.  Default is No (off).
; CleanXML=No

Probably don't need to worry about this setting to much unless you use custom XML parsers to create custom statistics for you server. If the XML parser cannot handle whitespace and linefeeds in XML, set this to Yes, and all should work.

Configuration Conclusion 

Your SHOUTcast Server should now be configured. For businesses that are using SHOUTcast, I recommend turning on WC3 logging, as it is easily parsable, and recommended for created custom statistics. You should also enable the AdministratorPassword. You might also wish to enable some of the mass configuration options if you're creating multiple SHOUTcast Servers.

With the configuration setup, we'll now work on getting SHOUTcast up and running. We'll start with simple on demand streaming for a simple startup, then work on SHOUTcast Trans later (as it is somewhat more involved).

2. Getting started with SHOUTcast Server

Setting up on demand streaming 

On demand streaming, as shown in the configuration chapter, automatically sets up on demand playlists for mp3 files in the content directory. The Shoutcast server ebuild has a directory setup in /opt/SHOUTcast/content for all your on demand mp3's. Let's get started by creating a simple on demand streaming mp3.

First we'll need to get an mp3 from somewhere and put it in the content directory. We'll take this sample.mp3 file from an /Mp3 directory I have created.

Code Listing 2.1: Copying an mp3 to the content directory

# cp sample.mp3 /opt/SHOUTcast/content/
# cd /opt/SHOUTcast/content/
# ls

Ok, so the file is copied over now. Now we'll need to startup our SHOUTcast Server so the file can be accessed.

Code Listing 2.2: Starting up the Shoutcast Server

# /etc/init.d/shoutcast start
 * Starting Shoutcast Server...
** SHOUTcast Distributed Network Audio Server
** Copyright (C) 1998-2004 Nullsoft, Inc.  All Rights Reserved.
** Use "sc_serv filename.ini" to specify an ini file.
                                                                         [ ok ]

The little banner is there to make sure that nothing dies right away (ie. so you know your server actually started). Your SHOUTcast Server is now started! Because of the nature of on demand content, you will ONLY be able to access it from a browser. MPlayer/XMMS/anything won't be able to stream it as is. I use kmplayer in order to access the stream directly from my browser. You can see the result on the next image.

Figure 2.1: On Demand Content

Fig. 1: OnDemandContent

Some people have XMMS setup to handle their audio mime types, so your browser may spawn XMMS up in order to play the resulting streaming content. Now that you are able to work with on demand content, we'll now work on using SHOUTcast Trans to create a true streaming radio server.

3. Setting up SHOUTcast Trans

SHOUTcast Trans introduction 

SHOUTcast Trans stands for SHOUTcast Trans(coder), as it is able to Transcode mp3's to lower or higher bitrates. SHOUTcast Trans works by streaming mp3's from a playlist specified in the configuration file. We'll begin to setup the configuration for SHOUTcast Trans, so that we can have a real to goodness streaming radio station. We'll begin by opening the configuration file for SHOUTcast Trans, which just so happens to be located in /etc/shoutcast/sc_trans.conf.

Code Listing 3.1: Opening the SHOUTcast Trans configuration file

# vi /etc/shoutcast/sc_trans.conf

Now that we have the SHOUTcast Trans configuration file open, we'll begin to setup the streaming source.

Configuring SHOUTcast Trans 

Code Listing 3.2: Setting up the playlist

; PlaylistFile (required EVEN IF RELAYING) - playlist file (to create, use
; find /path/to/mp3/directory -type f -name "*.mp3" > playlist_filename.lst

This setting tells SHOUTcast where to find its streaming media content from. This setting requires an existing file, so let's go ahead and create a playlist. I'll create one real quick from my /Mp3 directory referred to earlier.

Code Listing 3.3: Creating the playlist

# find /Mp3 -type f -name "*.mp3" > /opt/SHOUTcast/playlists/playlist.lst

Now that the playlist is setup, we point the configuration file to it, and SHOUTcast Trans will now know what files to stream.

Code Listing 3.4: Setting the server IP and port

; Serverip/ServerPort are the target server to send to

This setting decides where to send the streaming content. In this guide, it will be the SHOUTcast Server's IP and port that you setup previously (DestIP and PortBase).

Code Listing 3.5: Setting the SHOUTcast Server password

; Password is the password on the sc_serv you're sending to.

The is the same password that you setup in the SHOUTcast Server configuration.

Code Listing 3.6: Setting up your stream information

; StreamTitle/URL/Genre define the data that appears on the directory and in the
; stream info.
StreamTitle=Chris Gentoo Beats
Genre=JPOP Electronica And More!

This sets up the title of your stream (ie. Radio One), the url (ie., and the Genre (ie. Electronica Trance Tribal).

Code Listing 3.7: Setting up your logfile

; Logfile optionally denotes a text file to log sc_Trans to.  a kill -HUP
; will force a close and re-open of this file (but will also cease logging to
; the console)

This will point to the log file for SHOUTcast Trans. All your logging goes here.

Code Listing 3.8: Setting up shuffling

; Shuffle the playlist

Decide on whether or not you want your playlist to play random songs from your list each time. Most will set this to 1. If you're going to be accepting song requests, set this to 0 and I'll explain how to do that later on.

Code Listing 3.9: Setting up the stream

; Bitrate/SampleRate/Channels recommended values:
; 8kbps 8000/11025/1
; 16kbps 16000/11025/1
; 24kbps 24000/22050/1
; 32kbps 32000/22050/1
; 64kbps mono 64000/44100/1
; 64kbps stereo 64000/22050/2
; 96kbps stereo 96000/44100/2
; 128kbps stere0 128000/44100/2
; Quality is from 1-10. 1 is best, 10 is fastest.

Bitrate sets up the bitrate for your stream. This can be from 8000 (8kbps) to 128000 (128kbps). SampleRate sets the sampling rate of the stream. This can be anything from 11025 (11025khz) to 44100 (44100khz). Channels sets how many channels your stream will brodcast. This can be anything from 1 (mono) to 2 (stereo). Quality sets the stream quality. This is somewhat still controlled by the Bitrate/SampleRate/Channels. This is where you deal with how compressed the stream is. 1 gives you best quality, 10 gives you the best speed. Keep your connection in mind when you set these values! Use the guide given in order to figure out what your mp3's should be streamed at.

Code Listing 3.10: Setting up crossfading

; Mode=0 for none, 1 for 100/100->100/0, 2 for 0/100->100/0
; Length is ms.

This sets up song crossfading. Setting this to 0 will disable crossfading. If you set it to 1, Song 1 will fade out and Song 2 will fade in. If you set it to 2, Song 1 will fade in and Song 2 will fade out. The length is how long in ms the crossfade occurs.

Code Listing 3.11: Enabling ID3 usage


This decides whether or not you wish to use the ID3 tag for information about the mp3.

Code Listing 3.12: Setting up public status

; Public determines whether or not this station will show up in the directory

This sets up whether or not streams should be publically listed when relaying to a server. Remember PublicServer in sc_serv.conf can over-ride this!

Code Listing 3.13: Setting up user interaction

; Put stuff here for user interaction (AOL IM, ICQ, IRC)

This sets up the information on how to reach you (the dj). You can setup AIM or ICQ channels for song requests/anything. You can setup your own IRC channel as well, so that you can interact with multiple users at once.

SHOUTcast Trans Setup Conclusion 

Your SHOUTcast Trans is now ready to stream to your SHOUTcast Server! We'll now get started on streaming your mp3's.

4. Getting Started With SHOUTcast Trans

Starting up SHOUTcast Trans 

As I most often use SHOUTcast Trans with SHOUTcast Server, I tend to startup SHOUTcast Trans, which in turns starts up SHOUTcast for you (much easier). So we'll go ahead and get SHOUTcast Trans started.

Code Listing 4.1: Starting up Shoutcast Trans and Shoutcast Server

# /etc/init.d/shoutcast_trans start
 * Starting Shoutcast Server...
** SHOUTcast Distributed Network Audio Server
** Copyright (C) 1998-2004 Nullsoft, Inc.  All Rights Reserved.
** Use "sc_serv filename.ini" to specify an ini file.
                                                  [ ok ]
* Starting Shoutcast Trans...                     [ ok ]

Listening to the SHOUTcast Trans stream 

Now that SHOUTcast Trans is started, we'll start listening to the stream. I use MPlayer in this example to play the stream.

Code Listing 4.2: Listening to your stream

# mplayer -cache 1024
Connecting to server[]:8000 ...
Name   : Chris Gentoo Beats
Genre  : JPOP Electronica And More!
Public : no
Bitrate: 128kbit/s
Cache size set to 1024 KBytes
Connected to server:
Cache fill:  9.38% (98304 bytes)    Audio file detected.
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
MP3lib: init layer2 and 3 finished, tables done
mpg123: Can't rewind stream by 156 bits!
AUDIO: 44100 Hz, 2 ch, 16 bit (0x10), ratio: 16000->176400 (128.0 kbit)
Selected audio codec: [mp3] afm:mp3lib (mp3lib MPEG layer-2, layer-3)
Checking audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 44100 hz, little endian signed int
AF_pre: 44100Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
Video: no video
Starting playback...

This was somewhat clipped. The -cache variable was put in to over-ride my somewhat larger buffering settings. And viola! You're now listening to streaming media! In the next chapter, we'll show you how to do a little bit more with your SHOUTcast Server.

5. Advanced SHOUTcast Usage

Business Usage 

Businesses can use SHOUTcast in a number of ways:

  1. Use on demand content streaming to make more interesting daily announcements
  2. Have streaming public announcements avaliable as they happen, let your clients know what's going on, on the spot! Then archive them as on demand content streaming for future reference.
  3. Do interviews as streaming media and archive them as on demand content streaming.

There are more possibilities on how to utilize SHOUTcast Server for businesses. Use live streaming media instead of boring old text!

DJ-ing with SHOUTcast 

SHOUTcast Server is one of the most popular servers for both new and vetran DJ's alike. For those just starting, there are a few ways to increase the user experience of your SHOUTcast Server. Having an intro song is very key. It gives the users an idea of what your station is all about. Be sure to include this! Post your server on (described in the SHOUTcast Server configuration section) so that everyone knows where you are. One of the most unique things is to be able to take requests. To set up requesting, first turn Shuffle off in sc_Trans.conf. Have about, I'd say, 10 or so songs ready to get you started. Then start requesting song requests in the middle. When someone requests a song, simple add it to the end of your playlist, and then you can use this script here to control what SHOUTcast Trans does with your playlist:

Code Listing 5.1: djcontrol


case "$1" in 
		kill -s USR1 `cat /var/run/`
		kill -s WINCH `cat /var/run/`
		echo "Invalid command"

When you've addded the song to the playlist, you need to tell SHOUTcast Trans that your playlist has changed with the new request entry.

Code Listing 5.2: Reloading the playlist

# djcontrol reload

You should now let the users know after what song the requests will start. Or if you want, you can keep skipping with:

Code Listing 5.3: Skipping through the playlist

# djcontrol reload

Be careful not to skip too much, as there is no previous control. Once you hit their song, the requesting begins. I'd get about 5 or so requests before you start requesting. This way you don't run all the way back to the beginning. If you start to lack in requests and expect that your request hour is over with, then simply copy your next session's playlist over the requests playlist and reload the playlist. Once the current song is over, it will go back to the new playlist.


That ends it for the SHOUTcast Server and SHOUTcast Trans tutorial. I hope you benifited from the information here and please email me any comments or suggestions for this page! Enjoy your new streaming SHOUTcast Server!

The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.
Updated September 30, 2004
Chris White
Main Author

Summary:  This guide will walk through the steps needed to setup a streaming radio server with SHOUTcast Server and SHOUTcast Trans.
The Gentoo Linux Store
Copyright 2001-2004 Gentoo Foundation, Inc. Questions, Comments, Corrections? Email [email protected].