• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mc2739 - 2009-04-22
Last edited by kugel. - 2009-06-30

FS#10157 - inaccurate seeking while paused

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.

Closed by  kugel.
2009-06-30 00:21
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

Thanks for this. Committed in r21570.

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.

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.

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.

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.

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).

Same patch with more code comments.

This patch fixes the problem described in the details above, including the cuesheet problems.

Good job, Jeffrey!!


Available keyboard shortcuts


Task Details

Task Editing