Rockbox

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

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9306 - resume for m4a isn't consistent

Attached to Project: Rockbox
Opened by Kim Harbroe (starjasmine0516) - Wednesday, 20 August 2008, 23:24 GMT+2
Last edited by Andree Buschmann (Buschel) - Monday, 31 January 2011, 16:19 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

I use a sansa e200 to play m4a files. In the latest version of rockbox r18323M-080820, the bug still exists. I have a version that I use that does not exhibit this behaviour. it is: r17907-080701. Looking back at the daily builds, this lack of resume is still happening in r18043-080715. Steps to duplicate this problem. I have lengthy files. A test file can be found at http://www.sendspace.com/file/9s5x0l I have found that it doesn't matter whether I am at the beginning of a file or in the middle. It will sometimes resume perfectly when I press stop, power the play off, and then start it up and press play, while at others, it jumps to earlier in the file, or to another file altogether. Bookmarking that is created separately from resume playback's list works fine. This faulty resume will also work if the player is stopped, and then play is pressed.
This task depends upon

Closed by  Andree Buschmann (Buschel)
Monday, 31 January 2011, 16:19 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed with r29175.
Comment by Kim Harbroe (starjasmine0516) - Thursday, 21 August 2008, 09:58 GMT+2
This is my configuration file that I use when this behaviour occurs.
   config.cfg (0.5 KiB)
Comment by Frank Gevaerts (fg) - Saturday, 23 August 2008, 21:35 GMT+2
I can reproduce this on my c250 with default settings

Steps are:

* start playing
* seek to somewhere in the file, remember where
* pres Stop (long play on c200)
* shutdown the player
* start the player
* choose "resume playback"

Sometimes it will resume at another place in the file (I only had one file on the player). This seems to include times beyond the end of file, as sometimes the WPS shows a timestamp equal to the length of the file
Comment by Magnus Holmgren (learman) - Thursday, 28 August 2008, 21:22 GMT+2
This particular case isn't a length problem at least, so I suspect a buffering issue (the fact that it apparently started happening after a change to buffering.c suggests as much). Could be triggered by a call to rebuffer_handle (caused by the initial seek by the codec)...
Comment by Magnus Holmgren (learman) - Thursday, 28 August 2008, 21:33 GMT+2
Oh, when the problem happens, the following buffering.c logf messages are printed:

buffering >| Q_RESET_HANDLE 2
buffering < Q_RESET_HANDLE 2
reset_handle(2)
fill_buffer()
buffer_handle(2)
buffering >| Q_BUFFER_HANDLE 2
ata_sleep()
buffering < Q_BUFFER_HANDLE 2
buffer_handle(2)

(The handles are closed after this, and playback stops. Didn't have any other logfs enabled at this point, so I don't know why.)

Notice the ata_sleep() (which ought to be the call in fill_buffer), which is called due to buffer_handle being interrupted while processing the last handle. ata_sleep isn't supposed to be called in this case, queue isn't empty. Don't know if this is related to the resume problem though. :)
Comment by Andree Buschmann (Buschel) - Monday, 31 January 2011, 12:09 GMT+2
The attached patch uses alac_seek() instead of the malfunctioning alac_seek_raw(). As alac_seek() is seeking to a desired sample position we need to calculate this position from the desired byte position. As a result the seek is much more precise than with current svn. In svn seeking is off by up to 6 minutes on a 1 hour file, with this patch seeking is off by max ~30 seconds on the same file.
   m4a_v01.patch (1.6 KiB) 
 apps/codecs/aac.c        |   14 ++++++++++++--
 apps/codecs/libm4a/m4a.c |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

Comment by Magnus Holmgren (learman) - Monday, 31 January 2011, 15:42 GMT+2
If alac_seek_raw() really is the problem, wouldn't it be better to fix that, since that seek should be more exact (and not based on estimates from the overall file bitrate)? Any ideas what the problem is?

The byte offset is very close to the desired position (actual file offset at stop, minus pcmbuf latency times bitrate).
Comment by Andree Buschmann (Buschel) - Monday, 31 January 2011, 16:19 GMT+2
Found the underlying bug in alac_seek_raw(), submitted with r29175.

Loading...