Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

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

Attached to Project: Rockbox
Opened by John Romero (sssUSER) - Wednesday, 12 May 2010, 10:18 GMT+2
Last edited by Andree Buschmann (Buschel) - Saturday, 15 May 2010, 00:06 GMT+2
Task Type Bugs
Category Codecs
Status Closed
Assigned To Andree Buschmann (Buschel)
Player Type All players
Severity Low
Priority Normal
Reported Version Rbutil SVN
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

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?
This task depends upon

Closed by  Andree Buschmann (Buschel)
Saturday, 15 May 2010, 00:06 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed with r26032.
Comment by Andree Buschmann (Buschel) - Thursday, 13 May 2010, 15:02 GMT+2
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, 18:24 GMT+2
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) 
 apps/codecs/libmusepack/mpc_demux.c |   61 ++++++++++++++++++++++++++++--------
 1 file changed, 48 insertions(+), 13 deletions(-)

Comment by Andree Buschmann (Buschel) - Friday, 14 May 2010, 00:38 GMT+2
Code clean-up. Ready to submit.
   mpc_v02.patch (2.3 KiB) 
 apps/codecs/libmusepack/mpc_demux.c |   43 +++++++++++++++++++++---------------
 1 file changed, 26 insertions(+), 17 deletions(-)

Comment by John Romero (sssUSER) - Friday, 14 May 2010, 00:55 GMT+2
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) - Friday, 14 May 2010, 01:07 GMT+2
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, 11:06 GMT+2
Tested on h300, works fine and fixes the delay.

Loading...