From: Brian <gcadidas13_at_columbus.rr.com>
Date: Thu, 20 Feb 2003 07:13:14 -0500

I bring this back for discussion as i believe the delay between the time you press the button (like next) and when it actually switches the song is gradually increasing. I tried version 1.4 and there was a noticeable difference. All of my system settings were the same, also. I think this would contribute to Rockbox having a near-instantaneous button response when switching tracks, especially if you have it in your pocket and a lazy forward button that you dont know if you pressed fully. Does anyone else find this useful?

Brian


"langhaarrocker" <phil_at_x-phobie.de> wrote in message news:55n04vs15etv7c5b69ei64bajep7d02dj7_at_4ax.com...
> 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-20