Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by zagor - 2008-12-23
Last edited by zagor - 2009-01-10

FS#9703 - Better watermark handling

The 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.)

Closed by  zagor
2009-01-10 21:12
Reason for closing:  Accepted
Additional comments about closing:  

Committed in r19743

Project Manager
zagor commented on 2008-12-29 00:30

Massaged pcmbuf.c a bit. The pause/unpause bug is now fixed and also the excess boost is fixed.

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.

Doesn’t work at all here on my Fuze. I just hear a loud and constant hissing.
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.

Project Manager
zagor commented on 2009-01-01 00:22

Fixed an issue where codec thread would not cancel its’ elevated priority.

Definitely better now, but the issues are still there.
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%”).

Project Manager
zagor commented on 2009-01-01 20:33

I need help repeating your problem. I cannot see any difference in backlight fade speed between mp3 and ogg on neither c200 or e200.

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing