Rockbox

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

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10157 - inaccurate seeking while paused

Attached to Project: Rockbox
Opened by Michael Chicoine (mc2739) - Wednesday, 22 April 2009, 02:42 GMT+2
Last edited by Thomas Martitz (kugel.) - Tuesday, 30 June 2009, 02:21 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type SW-codec
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

r20769 and prior

Fails on device and simulator. Does not fail with flac, wma, ogg, wav

Steps to duplicate failure:
1) start playback of mp3 file (vbr and cbr both fail)
2) pause playback
3) seek forward and stop - this first seek after pausing will always stop where you release the seek button
4) seek forward again and stop - from this point, when you release the seek button, the track will back up 3 seconds from where it was when seek stopped
5) the same happens if you seek backward

This behavior is also causes problems with cuesheet support. If you pause an mp3 file that has a cuesheet and use the skip forward or reverse, it leaves you 3 seconds prior to where it should. Subsequent skip forwards are ineffective. Apparently, it skips to the next track in the cuesheet which is 3 seconds forward and then goes back 3 seconds, leaving you where you started.
This task depends upon

Closed by  Thomas Martitz (kugel.)
Tuesday, 30 June 2009, 02:21 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Thanks for this. Committed in r21570.
Comment by Boris Gjenero (dreamlayers) - Wednesday, 22 April 2009, 03:46 GMT+2
Actually, this seems to happen with all formats. If I do the same thing with FLAC in r20774 on a 5G iPod or 5G iPod sim, everything looks fine after the second seek. However, when I unpause after that, the time goes back 2 or 3 seconds. I also observed this in the sim with WMA. It's interesting how after pausing, the first seek leads to a bunch of codec_set_elapsed_callback() calls, and subsequent seeks lead to one or zero calls. The length of time (2 or 3 seconds) reminds me of the PCM buffer.
Comment by Michael Chicoine (mc2739) - Wednesday, 22 April 2009, 23:35 GMT+2
Since I first noticed this and thought it was a cuesheet issue, I did not notice the jumping back on unpause. I think it is interesting that it jumps back on pause with mp3 and unpause with the other formats.
Comment by Jeffrey Goode (Blue_Dude) - Wednesday, 24 June 2009, 20:40 GMT+2
I just found this error independently. The problem seems to be that when seeking while paused, the PCM buffer updates after seeking as it's supposed to, but only after releasing the FF/REW button the first time. After the first button release, you can seek again, but the PCM buffer does not update again. So when playback resumes, the buffer is full of samples from after the first seek and plays those, then "catches up" with the current position when the buffer runs out of old samples. I'm looking for a fix.
Comment by Jeffrey Goode (Blue_Dude) - Thursday, 25 June 2009, 05:22 GMT+2
I'm just not believing this. I've been at this thing all night, placing forensic logf's and whatnot, and the ultimate fix was one modification to one line. Here it is. Seeking, including multiple seeking while paused, now works as expected.
   seekfix.patch (0.4 KiB) 
 apps/playback.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment by Jeffrey Goode (Blue_Dude) - Thursday, 25 June 2009, 15:23 GMT+2
A little more detail on this fix of the codec_seek_complete_callback() routine.

The original problem was that after the first seek-while-paused, the PCM buffer was reset as required, but not after subsequent seeks, therefore after more seeks the PCM buffer was filled with content from after the first seek and would have to play them out before playing from the current seek location. This occurred because the condition to clear the buffer was only looking at the PCM play state. If it was paused, which is always is during the first seek, then the buffer was cleared after the seek. But the method used to clear the buffer was a play stop, which meant the PCM play state wasn't paused for the subsequent seeks - it was stopped. The initial solution was to change the condition from the PCM pause state to the playback paused state. (These are not the same. The PCM state is what the PCM play routine is actually doing internally. The playback paused state is true when a manual pause has been commanded). But this interfered with a seek-while-playing operation. A seek-while-playing pauses the PCM play state but does not pause the playback, and it needs the PCM buffer to be cleared as well. So the solution is to clear the buffer when *either* the PCM play state is paused (seek-while-playing) or playback pause is set (seek-while-paused).
Comment by Jeffrey Goode (Blue_Dude) - Friday, 26 June 2009, 20:36 GMT+2
Same patch with more code comments.
   seekfix.patch (1.1 KiB) 
 apps/playback.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

Comment by Michael Chicoine (mc2739) - Saturday, 27 June 2009, 07:11 GMT+2
This patch fixes the problem described in the details above, including the cuesheet problems.

Good job, Jeffrey!!

Loading...