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

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.

Comments (6)
Related Tasks (0/0)

Buschel commented on 2010-05-13 13:02

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 ""-comment. I need to dive deeper into the buffering concepts of the new decoder library to fix this.

Buschel commented on 2010-05-13 16:24

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.

mpc_v01.patch (3 KiB)

Buschel commented on 2010-05-13 22:38

Code clean-up. Ready to submit.

mpc_v02.patch (2.3 KiB)

sssUSER commented on 2010-05-13 22:55

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?

sssUSER commented on 2010-05-13 23:07

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.