Rockbox mail archiveSubject: Re: Buffer first few seconds of next song
Re: Buffer first few seconds of next song
From: roland <for_spam_at_gmx.de>
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 -----
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" <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
> 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...
Received on 2003-02-21