From: Mike Holden <rockbox_at_mikeholden.uklinux.net>
Date: Wed, 26 Feb 2003 00:21:55 -0000 (GMT)

Re this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=622799&group_id=44306&atid=439118
concerning rockbox lockups during playback, especially when on the move.

This is a problem I have been suffering from since the FM code became
stable enough to use on a daily basis. Rockbox is solid when the unit is
on a table, but when used on the move (walking, with the unit in a
pocket), I get this problem a lot with Rockbox, even though the original
Archos firmware is pretty solid in this respect.

I have been looking at this, and think I have found the solution, although
since it is an intermittent problem, and not reproducible at will, I can't
be certain!

Basically, I think we are too pessimistic if we get an error reading the
next chunk of an mp3 file. We do a read(), and if the status is < 0, we
basically give up immediately, even though the error is most likely due to
disk skipping. If we have got this far, we can be sure there is no serious
disk problem! I attach a patch for firmware/mpeg.c which basically treats
read() < 0 as a flag to queue another disk read to try again. This should
repeat until the anti-skip buffer is emptied. It could be argued that the
anti-skip buffer should be able to be bigger than 7 seconds, but that is a
separate issue.

I have given the new build a good thrashing with a brisk walk round the
village a few times, with no lockups in around an hour of use - who said
software development was unhealthy! Normally I would expect to get a
lockup within 10 or 15 minutes with a regular build of Rockbox.

I wanted to submit this patch to the list for discussion, since reading
mp3 files is pretty fundamental to Rockbox, and I am fairly new round
here! I also wondered whether putting a short sleep() in the code if
read() returns < 0, to give the hardware a bit of time to recover after a
skip.

Mike Holden



Received on 2003-02-26