[Icecast] relation between burst- and queue-size with low bitrate streams

[Klaas Jan Wierenga]

Hi all,

I have a question about the relationship between the "queue-size" and the
"burst-size" <limits> parameters.

	Q: When a client connects is the burst-size immediately added to the
queue-size?

If this is the case then the slack for a 16kpbs client goes down from 50 sec
(102400[queue-size] / 16kbps = 50 sec) to 18 seconds ( (102400 -
65536[burst-size]) / 16kpbs = 18 sec).

I'm experiencing quite a few of the following lines in the DEBUG logging. It
could be that the clients are really running too slowly, but chewing 32secs
of the slack probably woudn't help either.

Background info
===============
I'm running an icecast-2.1 mp3 streaming server where a few hundred
listeners connect to a few tens of streams at 16 and 24 kbit/s bitrate.

Listeners connect using a device which is dialing in using a 56kbps analog
modem. Some listeners experience poor stream stability at times, meaning
that the stream repeatedly skips (with pauses of around 20-30 seconds).

I've looked at various reasons for this behaviour such as bad connect speed
of the 56K modem and possible lack of bandwidth on the streaming server but
these do not seem to be the problem. The modem connect speeds are > 38Kbps
and there is enough bandwidth available to the streaming server.

I've switched on DEBUG logging and I am seeing these lines quite regularly:

[2005-02-09  20:38:57] DBUG source/send_to_listener Client has fallen too
far behind, removing

I have a hunch that the burst-size and queue-size might have something to do
with this. The limits section of my icecast.xml reads:

    <limits>
        <clients>2000</clients>
        <sources>100</sources>
        <threadpool>10</threadpool>
        <queue-size>102400</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>30</source-timeout>
        <!-- If enabled, this will provide a burst of data when a client
             first connects, thereby significantly reducing the startup
             time for listeners that do substantial buffering. However,
             it also significantly increases latency between the source
             client and listening client.  For low-latency setups, you
             might want to disable this. -->
        <burst-on-connect>1</burst-on-connect>
        <!-- same as burst-on-connect, but this allows for being more
             specific on how much to burst. Most people won't need to
             change from the default 64k. Applies to all mountpoints  -->
        <burst-size>65535</burst-size>
    </limits>

Any suggestions would be appreciated.

Regards,
Klaas Jan