Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Codecs
  • Assigned To
    Buschel
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Rbutil git
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by sssUSER - 2010-05-12
Last edited by Buschel - 2010-05-14

FS#11261 - Newer Musepack Codec slows seeking to a crawl!

I am surprised no one has mentioned this. I am running a 1st Gen Ipod Nano and I have noticed that new builds containing the rebuilt musepack codec have a significant delay before continuing playback after a seek (as in 10-15 seconds). This may depend on the musepack encoder you use, but seeking was instantaneous for me in 3.5.1. Playback works fine, I am using r25961 right now but this change looks like it was done on r25056 (http://svn.rockbox.org/viewvc.cgi?view=rev;revision=25056). Fortunately I know how to revert to the old musepack code, but I think the bug needs squashing don't you?

Closed by  Buschel
2010-05-14 22:06
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Fixed with r26032.

You found a missing optimization. In my tests I did not recognize this…

The current code seems to throw away and re-read buffers for each frame when scanning the file the first time. This does only happen when seeking forward to file positions that were not played or scanned before. Seeking backward is instant as well as seeking forward to formerly scanned or played positions.

In fact the code sequence has a "FIXME"-comment. I need to dive deeper into the buffering concepts of the new decoder library to fix this.

This patch shuld resolve the issue. Now the code checks whether the needed bytes have already been buffered. If so, it does not flush the buffer. On my iPod the search is now quite fast. Please test and give feedback.

Code clean-up. Ready to submit.

The patch works! Seeking only takes a short time now, it's not quite as fast as seeking with mp3, but it is close enough.

When will this be committed?

I might add that I only tested the first patch, so if you made optimizations in the second one, I have not seen them.

nls commented on 2010-05-14 09:06

Tested on h300, works fine and fixes the delay.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing