This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9703 - Better watermark handling
Attached to Project:
Rockbox
Opened by Björn Stenberg (zagor) - Tuesday, 23 December 2008, 23:04 GMT+2
Last edited by Björn Stenberg (zagor) - Saturday, 10 January 2009, 22:12 GMT+2
Opened by Björn Stenberg (zagor) - Tuesday, 23 December 2008, 23:04 GMT+2
Last edited by Björn Stenberg (zagor) - Saturday, 10 January 2009, 22:12 GMT+2
|
DetailsThe current watermark handling is quite hardcoded at 512KB, which is a problem for targets with a small file buffer.
It is also of course not optimal for battery performance. This patch instead calculates the watermark based on the bitrate of the last file in the buffer and the measured harddisk spinup time. (This code is not ready for commit.) |
This task depends upon
Closed by Björn Stenberg (zagor)
Saturday, 10 January 2009, 22:12 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed in r19743
Saturday, 10 January 2009, 22:12 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed in r19743
Still to do:
1) Understand pcmbuf.c better, in order to determine if I like how it works. :-) In any case it needs documentation.
2) See if I can find a clean way to export buffering information to playback.c, in order to include total and buffered file size for the last track in the watermark algorithm.
I have tested this on Iriver H140, Sansa C200 and Sansa Clip so far. I would appreciate some test reports for other targets.
The debug screen shows that audio buffer decreased, but the pcm buffer apparently jumped back and forth between 2 values (the 2 values are constant it seems).
I tested with a Flac, other codecs (aac, vorbis, mp3) still don't give any sound at all.
Playing FLAC and Mp3 seems fine now.
However: Ogg still causes slowness. It's much better than with watermark2, but the gui lags and backlight fade slowness are still very noticeable compared to SVN.
From the View OS stacks screen I can see, that with this patch codec is constantly *R. In SVN, it's changes between +R, *R and S freqeuently. The numbers are the same ("16 16 18%").
The codec thread runs more frequently since the PCM buffer is a third of the size in SVN. But it should not (and does not, afaik) boost more than SVN.