dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Buffer first few seconds of next song

Re: Buffer first few seconds of next song

From: roland <>
Date: Fri, 21 Feb 2003 00:09:04 +0100

YES ! YES and YES !
I would completely agree with all points Phils posted some time ago. Phils thoughts about this are very good !
I also have spent many thoughts on a feature like this- but because I`m bad programmer I just had in mind to post a request on this list, too. :)
(Didn`t know it is already there as feature request #668528. Unfortunately it is given a priority of "2" - I find this is worth being given at least a "6" or "7")

I`m sort of "crazy zapper" and would like it very much, if my archos would behave less sluggish and more responsive when zapping through the playlists.
pleaaaaase - someone implement this in an intelligent manner (dynamic recognition of "browsing behaviour") ;)


----- Original Message -----
  From: Brian
  Sent: Thursday, February 20, 2003 1:13 PM
  Subject: Buffer first few seconds of next song

  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?


  "langhaarrocker" <> wrote in message
> 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-21

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy