Icecast Streaming Media Server

[Anonymous]

Hello,

new to Icecast streaming so I wonder if somebody can explain me the meaning/relation of burst-size and queue-size.

Background:
I have setup an Icecast server with a queue-size of 524288 and a burst-size of 16384.
Randomly, (after 5-6 hrs) the client gets disconnected due to "fallen too far behind" error.
This problem for sure is related to some kind of net congestion, but I wonder if adjusting the queuesize or burstsize would improve the situation.
The intend of the server is to supply an audio signal to one of our remote broadcast locations. So a minimal time delay to the source signal is mandatory, on the other hand the client should not get disconnected due to network problems.
Streamer is darkice and bitrate 96kbps.

regards:
-Serge-

[karlH]

The queue size is the maximum amount of stream data that can be stored for a single stream. If any new stream data takes the queue above that limit then the queue is cut back and any listeners who were referencing that data will be disconnected with that message you have seen. The burst size is where new listeners start from within that queue.

If the listeners are suffering congestion or limits like TCP flow control then there isn't much icecast can do. Increasing the queue size will just mean that they stay on for a bit longer, so is only usful for short lived congestion.

karl.

[Anonymous]

Thanks Karl for the prompt reply!

Ack for queue size. But I don't really understand the importance of the burstsize then.

1) Any burst (whatever size) gives you a delay related to the live data.
2) It reduces the amount of the queuebuffer by the amount of burstsize.

So what's the reason behind? Maybe I misunderstood this.

Best regards from Luxembourg:
-Serge-

[MikeS]

Burst-on-connect is ONLY useful for reducing the delay between initial connection, and start of playback, for common clients which require a certain amount of buffered data locally before they'll begin playback.

If you're in any way interested in low-delay, you should disable it.

At the size you've selected, it's unlikely that increasing the queue size will help with the problem - it might delay it, but no more. Also, if you're approaching this limit, your latency will be increasing.

The most common reason for that, assuming a fast enough network connection between server and client, is that the clock on the client doesn't accurately match (in rate) the clock on the source that's creating the stream. Smarter clients will interpolate an accurate clock from the incoming datastream, but that's quite difficult, and not generally implemented in http clients.

Mike

[Anonymous]

Thanks Mike for the update.

I don't believe on a clock problem, as we had the Server and Client running for weeks without interruption on the same Network (LAN-side)

Now that we are running our tests with a DSL Line connecting both sites together, we are facing this problem.
Looks like we have to monitor line speed on both ends to track down the reason for this.
Thank you both, Karl and Mike, for your professional help on this matter!

regards:
-Serge-