(cut-n-paste'd from Dean's posting to the dev' list)

You are right, this is a definite problem for many streams.  Some low bitrate
streams do allow substantial prebuffering and will start up quickly, but some do
not.
  In general, we don't know the bitrate of the stream (it might be VBR) but we
do have two ways to guess:

1.  The inclusion of a bitrate header "icy-br" may indicate the intended bitrate.
2.  Measure the rate of data as it comes in.

Either way, I think that the best measure would be to max out the pre-buffering
time at some duration, say 10 seconds, and start playing even if the buffer
isn't full.  If it runs out, then it's likely that the station isn't going to be
able to sustain playback in any case.

And including a warning saying that we're buffering is a really good idea and
shouldn't be that hard to implement...

Could you create a bug on https://bugs-archive.lyrion.org with your thoughts (and
mine) so we can track this and make sure it gets fixed?

thanks,

dean

On Jul 22, 2004, at 9:31 AM, Jim wrote:

> I've been working with the Live365 plugin and I've come across a shortcoming
in Slimserver...
>
> The size of the streaming buffer is constant (eight seconds of 128kbps), and
the player stays in a "buffering" state until it fills half the buffer.
>
> For low bandwidth streams, this can lead to very long delays (upwards of 15
seconds) during buffering where no sound is output, and there's no indication of
what's happening.
>
> The research I've found on dynamically recalculating buffer sizes based on
traffic patterns involves math that's beyond my skills to implement, and it
possibly unnecessary anyway.
>
> So to my question: how does the SqueezeBox know what the stream bitrate is? If
a program could get that, as long as we're looking at CBR streams, the buffer
size could be dynamically and easily computed to minimize buffering delay on a
per-client basis.
>
> Alternately, a "Buffering: xx% complete" message on the display would at least
give some indication of activity, but then you're looking at a message instead
of listening to music...
>
> Jim
>
> _______________________________________________
> Developers mailing list
> Developers-8kkgcvHRObwvDzVnOqYaopqQE7yCjDx5@public.gmane.org
> http://lists.slimdevices.com/lists/listinfo/developers
>