Icecast Streaming Media Server

[baalpeteor]

I was wondering as a rule of thumb how does bandwidth match up with users at a given bitrate... here's a lab

Let's say I have a 64 kbps for low bandwidth and 128 kbps for high bandwidth. I expect to have nomore than 50 users at a time.. 40 high bandwidth 10 low bandwidth.

What kind of bandwidth should I have from AT&T or cox or whoever to accomodate this to get rid of buffer times?

Also if I drop it to live or near live (maybe 1 to 3 second buffer) wouldn't I need alot better internet? I currently have a 6/7 second buffer and in the morning when 10 or 13 people or so are on (11 high rest low) it can start buffering or people have told me it does. Now the computer is also an old pc with just 128 mb memory and prob 2. something ghz. The bandwidth we have now I believe is 768 kbps upstream... i forget the downstream but don't quote me to hard. I would have to run another speed test in person instead of over vnc.

Our station we have had the most of 14 high and 11 or 12 low bandwidth at once. I want it to be stable at at least 3 second to 2 second buffer running 25 livel isteners at 128 kbps... that is if its possible and affordable without needing fiber (the city is running our own private fiber line just for this city now). I can go with Cox or AT&T (cable and dsl) or I guess T1 if it isn't too much.

[baalpeteor]

oh and is there a graph for this? If not that would be useful to make. Like the X access at the top is users and the y access on the left is bandwidth and you could do one for each bitrate or at least 128, and 64 you would just double it.

[karlH]

10*64 + 40*128 so total bandwidth is less then 6Meg/s. While this is the max link required at your end there are still concerns fort the server to player link. You'll want to make sure that the TCP windows can be large enough to handle any low latency links or else they will starve and drop down.

Low latency is not usually a concern for most people as there is no reference for the listener for comparison, but if you do want the lowest you can then you'll need to lower the burst size to represent the delay you want, eg 2 seconds @ 64kbps is a burst size of 16384 but the players may have setting of their own in which they will prebuffer a certain amount before playing, this could be 64k for instance.

karl.

[baalpeteor]

[karlH]

buffering does not lower bandwidth, it just provides to a delay (adds latency) to allow for minor stalls in the throughput, because you'll notice the smallest of glitches on the audio playback. The typical way to reduce bandwidth is to use a better codec or to spread the load across several servers.

you'll want some buffering especially over a medium like the internet. Whether a 2-3 second burst is ideal is hard to say as there are many factors that are not defined. You say you find 6 seconds rather high, ok, but why, what makes 6 seconds delay a problem for you?

icecast will allow the burst to be configurable and you could relay a stream on a different mountpoint with a different burst.

karl.

[baalpeteor]

[karlH]

There is work in the next FF for native vorbis decoding and there is some work for flash 10 at http://barelyfocused.net/blog/2008/10/03/flash-vorbis-player/

karl.

[baalpeteor]

[karlH]

Use a hosting provider that runs the server for you (either icecast specific or dedicated hosting). Domestic connections are not going to be suitable for many listeners.

karl.

[baalpeteor]