|
Rockbox mail archiveSubject: Re: Buffer first few seconds of next songRe: 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") ;) regards Roland ----- Original Message ----- From: Brian To: rockbox_at_cool.haxx.se 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? 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-21 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |