[icecast] using a web server?

[Jack Moffitt]

> 1) A web server won't concatinate songs together, but if someone is
> only downloading say a one-off clip, perhaps a web server is exactly
> what is needed

No, but if you send a playlist or m3u with more than one song, there's
no need for the webserver to concatentate them.  This is how some large
sites work.  LaunchCast did it this way.  I believe ImagineRadio
(SonicNet Radio) did it this way too.  

> 2) Titles (or rather meta-data) don't get inserted into the stream,
> though they could somehow be inserted into the file ala shoutcast
> style

Many would claim this doesn't happen on icecast either.  And with vorbis
this isn't an issue.

> 3) icecast seems to pace sending out it's packets so as to not overrun
> the receiver.  This doesn't seem necessary since tcp does this
> automatically.  Perhaps it doesn't do this and I'm reading the code wrong.

Icecast doesn't do this.  It sends data to clients as fast as it
receives data from sources.  For _real_ streams, ie, realtime data, you
don't need to pace, as the data is generated in realtime.  For simulated
realtime stream, the source program has to pace the data.  If a client
reads to slow on an apache stream, no big deal. apache will wait.  If a
client reads data from an icecast stream too slow, it won't work.  The
realtime nature of the data means we have to send the data in time.  Too
slow, or too fast is unacceptable.

> So, aside from these reasons, why would someone put up a streaming
> audio server to stream static files (i.e. click here to listen to this 
> song, rather than listening to a concatinated stream)?

It depends.  Some people want radio functionality.  Ie, tune in to some
radio program.  You may start in the middle of the song or just before
the end.

Others want to have music stream, meaning that you click and it starts
playing instead of downloading.

I say there are 3 types of streams:

1) Live stream.  recording from the soundcard and encoding live, etc.  
2) Simulated live streams.  reencoding on teh fly or sending
concatenated mp3s/oggs to the server.  It looks like it's live, but it's
been preencoded.

3) on demand streams.  click on a file, hear it instantly.

icecast is built to handle 1 and 2.  And not really for 3.  On the other
hand, Apache was built for 3 and not for 1 or 2.

Use the right tool for the job.

In some extreme cases, icecast may be the right tool for the job in #3,
but not unless this user is going to spend time tweaking it to work.  I
haven't seen a case of on demand streaming that couldn't be solved by
apache and a farm of boxes.

> I know some of you folks out there have put together perl scripts and
> php scripts to do a sort of juke box with icecast, I'm just wondering
> what the reasoning is.

Perl and PHP are easier to hack on than icecast.

jack.

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.