From: langhaarrocker <phil_at_x-phobie.de>
Date: Wed, 05 Feb 2003 02:13:36 +0100

>Feature Requests item #668528, was opened at 2003-01-15 16:31
>Submitted By: Mark Snyder (mesnyder)
>
>A feature I would find useful would be a configurable
>next song buffer. The first few seconds of the next
>track would be stored in RAM, so that if next is
>pressed, the next song would begin playing immediately.
>The size of the buffer in seconds and the number of
>tracks to prebuffer should be configurable.
>
>----------------------------------------------------------------------
>
>>Comment By: Daniel Stenberg (bagder)
>
>I find this to be a silly idea. The most common case must be
>that you DONT use the next button and thus it should be
>optimized for that. Also, reading parts of the following
>song instead of a bigger chunk of the primary one, will make
>reading the primary song slower.

I take this topic to the mailing list because I think it's better to
discuss it here.

I don't think this idea is that silly. I rather consider the latency
of skipping a track as a major drawback of the jukebox.

But when I watch my own behaviour I recognize that I make the decision
to skip or not to skip a song in the very first few seconds of a song.
Based on this observation the prebuffer-algorithm can be more
intelligent.

1. We don't need the buffer size of the 'next-buffer' to be
configurable since we can calculate it (== low watermark * 2).

2. I believe that more than one 'next-buffer' is a waste because the
user needs a little bit of time to recognize the song.

3. We don't need to keep the buffer all the song. If the current song
has been played so long that the low watermark has been reached once
we may assume that the user wants to listen to the song completely.
Thus we may drop the 'next-buffer' and reuse that memory for the
current song.

4. Only when a track change occurred we have to preread the next song
and fill the 'next-buffer'. This is why the 'next-buffer' size must be
twice its low watermark: We need time to read some data of the current
and of the next song. We want the 'next-buffer' to be filled as soon
as possible but without endangering that we run out of data of the
current song.

5. (optional) If we detect that the user keeps on skipping songs we
might switch over to a 'browse-mode'. In this mode we prebuffer
servaral tracks. Again the low watermark can be used to calculate the
amount of data that must be buffered.

6. (optional) If we detect that the user keeps skippings backwards we
may want to turn the 'next-buffer' into a 'previous-buffer'.


Just a few thoughts...

Phil
Received on 2003-02-05