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

Attached to Project: Rockbox
Opened by John Romero (sssUSER) - Wednesday, 12 May 2010, 08:18 GMT
Last edited by Andree Buschmann (Buschel) - Friday, 14 May 2010, 22:06 GMT
Task Type Bugs
Category Codecs
Status Closed
Assigned To Andree Buschmann (Buschel)
Operating System All players
Severity Low
Priority Normal
Reported Version Rbutil SVN
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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 (;revision=25056). Fortunately I know how to revert to the old musepack code, but I think the bug needs squashing don't you?
This task depends upon

Closed by  Andree Buschmann (Buschel)
Friday, 14 May 2010, 22:06 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with r26032.
Comment by Andree Buschmann (Buschel) - Thursday, 13 May 2010, 13:02 GMT
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.
Comment by Andree Buschmann (Buschel) - Thursday, 13 May 2010, 16:24 GMT
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.
Comment by Andree Buschmann (Buschel) - Thursday, 13 May 2010, 22:38 GMT
Code clean-up. Ready to submit.
Comment by John Romero (sssUSER) - Thursday, 13 May 2010, 22:55 GMT
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?
Comment by John Romero (sssUSER) - Thursday, 13 May 2010, 23:07 GMT
I might add that I only tested the first patch, so if you made optimizations in the second one, I have not seen them.
Comment by Nils Wallménius (nls) - Friday, 14 May 2010, 09:06 GMT
Tested on h300, works fine and fixes the delay.