i c e c a s t   f a q
 ` ` ` ` ` ` ` ` ` `

** General Questions **
Q1. What is icecast?
Q2. Where can I get icecast?
Q3. Icecast, liveice, shout, iceberg, icedir and icesource. What do they all do?
Q4. What platforms are supported?
Q11. What are the future plans for icecast?

** Directory Server Questions **
Q5. What do I need to setup and run an icecast server?
Q6. What do I need to run a directory server?

** Questions about listening **
Q7. How can I listen to icecast streams?

** Questions about streaming **
Q8. How can I broadcast icecast streams?
Q9. Does icecast work with WinAmp?
Q9.1 Why won't winamp work when streaming to icecast?

 * Questions about shout *
 * Questions about liveice *

** Questions about mpeg encoding */
Q12. What is the playback quality like?

** Server related questions **
Q13. What's the story with crypted passwords?
Q14. What's libwrap (tcp_wrappers), and how do I use them?

IV. Remote administration
Q15. What's the remote admin console for?
Q16. What's an Icecast Operator?
Q17. How do I make my server show up on both icecast.linuxpower.org
     and yp.shoutcast.com (or others)?
Q18. How do I change encoders without dropping clients?
Q19. How do I renice icecast and shout to improve performance?
Q20. What's the best mpeg player to use with icecast?
Q21. Why doesn't shout work with shoutcast servers anymore?

Q1: What is icecast?
A1: icecast is an internet audio broadcasting system based on Mpeg audio
    technology.  It allows almost anyone to broadcast an audio stream
    to as many people as their bandwidth can support.

Q2: Where can I get icecast?
A2: The icecast home is http://www.icecast.org/.  You can find icecast
    news, the latest source releases and patches, and links to some servers
    which are broadcasting publicly.

Q3: Icecast, liveice, shout, iceberg, what do they all do?
A3: Icecast is the name of the whole broadcasting system. It is also the name
    of the server. Liveice is a live encoder (streamer). Shout is a static file
    streamer. Iceberg is a GTK+ tool to do remote administration. Icemaker is
    a win32 tool to do live encoding. Iceplay is a no longer used perl script
    that does static streaming. All are, or will be (when they're done),
    included in the icecast system.

Q4: What platforms are supported?
A4: Depends on what part of the icecast system you want to use.
    Icecast runs on Windows 95/98/NT, and sane unix systems with support for Posix Threads. 
    Notably, Linux glibc 2.0 and above, FreeBSD, Solaris, newer versions of Irix and HP-UX.
    Shout runs on win32 and just about any sane platform.
    Liveice runs on Linux and FreeBSD, and has limited support for Solaris and 
    Digital Unix (no soundcard support).
    Icedir will run on any system with apache and mysql installed.

Q5: What do I need to setup and run an icecast server?
A5: First of all you need a box to run the server.  Download and compile
    icecast on this box, and start it up (the default config should be fine).
    Next, you will need to send your server an audio stream from an encoder.
    Use liveice if you want to stream a live encoded stream from the soundcard,
    or reencode songs at a different bitrate.
    Use shout if you just want to stream files as-is, at the bitrate they are
    encoded at.
    If you have to use a windows for the streamer, you have these options.
    Either use the win32 version of shout. Or, wait for us to complete icemaker,
    a win32 application that does live encoding. Or, use the dsp plugin for
    winamp.
    Then, to get listeners to your server, add your streams some of the directory
    servers out there, like yp.icecast.org and yp.mp3.de (more listed in the 
    configuration file).

Q6: What do I need to run a directory server?
A6: We designed icedir for Apache environments with MySQL for a database and
    PHP for the scripting.  These programs are freely availble and compile
    on almost anything. Once you have those set up, there are directions
    on how to set everything up in the icedir README file.  The directory
    server could easily be rewritten in Perl using textfiles or DB files,
    and you are free to do this if you wish.

Q7: How can I listen to icecast streams?
A8: We're happy to say that almost all mp3 clients out there now have
    streaming capabilities. Some have more streaming features than others,
    and not all clients are really stable. For Unix XMMS (www.xmms.org) is the 
    best choice, but mpg123 (mpg.123.org) and xaudio (www.xaudio.com) clients work 
    fine too.
    For Windows, we recommend Sonique (www.sonique.com) or K-Jofol (www.kjofol.com),
    or perhaps Winamp (www.winamp.com).

Q8: How can I broadcast icecast streams?
A8: Use one of the streamers, see Q5.

Q9: Does icecast work with WinAmp?
A9: Yes.  One of the initial goals was to provide compatibility with both
    WinAmp as well as Shoutcast.  You can send audio streams to icecast
    servers with WinAmp as well as listen to icecast streams with WinAmp.
    But.. since we don't fully agree with the way Nullsoft has designed
    some of the things in their audiocasting software, we've decided not
    not follow shoutcast development 100% anymore. You will always be able
    to listen to icecast streams with winamp, but it will not support all
    of the nice icecast features unless Nullsoft implements them into winamp.

Q9.1: Why doesn't winamp work when streaming to icecast?
A9.1: What I've found is that the Shoutcast DSP actually uses two IP ports which you need 
      to take care of. If you set the Shoutcast DSP to use port 7999, then the DSP uses 
      port 7999 to send information *about the stream* (number of listeners, etc) between 
      the shoutcast server and the dsp; and port 8000 for the stream data itself. I call 
      the former port the "metadata port" and the latter the "data port", to avoid confusion. 
      Icecast does not use or know about the "metadata port", so you need to do something 
      about that. If you set up your icecast server just to listen on the data port and don't 
      do anything about the metadata port, everything seems to work ok at first, but eventually 
      the machine running your DSP be unable to use the network at all. That is because the 
      dsp keeps on trying different local ports to reach the remote metadata port on the server, 
      without releasing local ports that fail. Eventually, after about an hour of streaming, you 
      run out of local ports and you can't do *anything* over IP until you shut down the DSP and 
      release those ports. 
      A solution is to set up another instance of icecast to listen on the metadata port. So you 
      start one instance for the data, and one for the metadata. Of course, icecast doesn't _do_ 
      anything with the metadata stuff, it just kicks the connection right away. But this stops 
      the DSP from trying a different local port every time; it just retries the same local port
      each minute or so and then the shoutcast server just kicks it again. This effectively solves 
      the problem. Yes, it's a hack, but it works. 
      So: to summarize: if you want to broadcast on port 8000: 
	1) Set up two instances of icecast, one to use port 7999 (metadata), and another to use 
	   port 8000 (data). Or one instance of icecast listening on both ports.
	2) set up your shoutcast DSP for port 7999. 
        3) Bust and move old-school style. 
        
Q11: What are future plans for icecast?
Q11: We feel that with the release of icecast 1.3.1, the server has started
     to look much more stable. It's not cpu intensive, and it doesn't use
     much memory. So we're quite happy with the current design. Featurewise
     we have started looking at multicast and rtsp support. That will mean
     a lot for audiocasting technology. We also intend to have an embedded
     interpreter in icecast. A script language, to allow for flexible, runtime
     configuration and other stuff that is more suited for interpreted languages.
     We have not yet decided what language to use, TCL, perl, Python, Scheme, it's
     still up for discussion :)
     We will also extend the static file http download capabilities in icecast to
     exchange playlists between servers and keep one big "virtual" file server of
     mp3 files.

Q12: What is the playback quality like?
A12: The playback quality on average is really, really good.  MP3 files are
     reknown for their excellent sound quality, so those of you with MP3
     experience already know what to expect.  In general it seems quality
     can vary by encoder, but overall an Mpeg stream is better than a 
     RealAudio stream at 50% more bandwidth.  That means that a 16kbps icecast
     stream can sound better than a 24kbps RealAudio stream.  And of course,
     bandwidth allowing, you can send near CD quality streams at 128kbps,
     which sound GREAT!

Q13: What's the story with crypted passwords?
A13: Normally, icecast and shoutcast servers keep the passwords uncrypted,
     either in a configfile, or specified on the command line. This is pretty
     poor security. Newer versions of icecast provide a configuration option
     (--with-crypt). With this option, then the passwords in the configuration
     file (icecast.conf) and the ones specified on the command line, should
     be crypted. To produce these crypted passwords, use the mkpasswd program
     distributed with icecast. Be careful in the configuration file not to
     leave any junk chars after the passwords.

Q14: What's libwrap (tcp_wrappers), and how do I use it?
A14: Sometimes you want to restrict access for clients, admins, and encoders,
     not only on a password basis, but on a hostname basis. You want to
     be able to specify which hosts should be allowed to listen to your
     server. Newer versions of icecast (when configured with the --with-libwrap
     option), make use of the tcp_wrappers package by Wietse Venema, which
     means that you can use the files /etc/hosts.deny and /etc/hosts.allow,
     to do host based access control. The tcp_wrappers package does not come
     with icecast, you need to download and compile it yourself. It does
     work with all sane versions of unix, and you can download it from
     most security related ftp sites (like ftp.cert.org).
     For instance, if you want to restrict icecast access on your server
     to the 130.236.235.* network, then add the line to /etc/hosts.deny
     icecast: ALL
     And this to /etc/hosts.allow
     icecast: 130.236.235.

Q15: What's the remote admin console for?
A15: The only way of controlling the server (when not using the remote admin
     console), is from the window where you started the icecast server process.
     This is really limited, so we suggest you make use of the remote admin
     console. You simply fire up a telnet client, and connect it to the
     remote admin port (8000 unless otherwize specified). Now type the 
     remote admin password, and you're in. There are some commands available
     right away, but most of the goodies require a second password; the
     operator password. Type 'oper <password>', and if you're in luck then
     the server replies with "You are now an Icecast operator". The current
     list of commands (you can get it by typing help) is available under
     Remote Admin Console in the README.

Q16: What's an Icecast Operator?
A16: Simply a remote admin that has used the oper command with the correct
     password. Similar to an IRC operator.

Q17: How do I make my server show up on both icecast.linuxpower.org
     and yp.shoutcast.com?
A17: Simple, either use the command line option -d <server> several times
     like so: icecast -d icecast.linuxpower.org -d yp.shoutcast.com
     Or in the icecast.conf file, use the directory keyword several times
     like so:
     	directory yp.icecast.org
     Current versions of icecast use a newer directory protocol than is 
     used by shoutcast directory servers.  To have your server show up 
     on these, use the icydir keyword in the icecast.conf file like so:
     	icydir yp.shoutcast.com

Q18: How do I change encoders without dropping clients?
A18: This is possible, and simple, but most mp3 players will die when you
     do this, because the stream will get out of sync.
     Connect the second source to the server, and when you want to switch
     encoder, use the 'select <id>' command in the remote admin console.
     To know what id to use, you can first use the 'sources' command, which
     displays the id for each encoder in the first column.

Q19: How do I renice icecast and shout to improve performance?
A19: You don't need to renice icecast except when you are serving a large
     number of clients (and even then it's not really necessary unless you
     notice performance problems).  In any case, you can run renice (niceness)
     -p (pid), where niceness is something negative, like -5 or -10, and (pid)
     is the pid of the icecast process.  You have to be root to renice to a
     negative niceness.

Q20: What's the best mpeg player to use with icecast?
A20: At the moment, not all players can handle http streaming. The ones I've
     tested are xmms and mpg123 (0.59q). xmms is far better, almost as
     stable as winamp. Under Windows, you can use Sonique, K-Jofol, or Winamp.

Q21: Why doesn't shout work with shoutcast servers anymore?
A21: Shout (as shipped with 1.3 and above) defaults to using the new
     x-audiocast headers. Shoutcast (and icecast pre 1.3) servers wants the
     old icy headers. Add the -i flag to shout to make it print icy headers,
     and all will be well.