FS#10335 - End of file not played at end of playlist

Attached to Project: Rockbox
Opened by Jeffrey Goode (Blue_Dude) - Monday, 15 June 2009, 04:21 GMT
Last edited by Dan Everton (safetydan) - Wednesday, 17 June 2009, 08:48 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The last thousand or so samples of a file are not output when played as the last file in the playlist.

To duplicate, play the attached file with another file following it in the playlist, even itself using repeat. There is a distinct chirp at the very end that will be played if another file follows, which is correct. However, if the file is played at the end of the playlist, the chirp is not played. The last samples are omitted from playback.

This behavior occurs on the Sansa e200 target and in the Sansa e200 simulator build. It also occurs on other simulator builds: iriver H120/H140, Creative Zen Vision, and iPod Nano. I didn't try to build others.
This task depends upon

Closed by  Dan Everton (safetydan)
Wednesday, 17 June 2009, 08:48 GMT
Reason for closing:  Accepted
Additional comments about closing:  Thanks!
Comment by Jeffrey Goode (Blue_Dude) - Tuesday, 16 June 2009, 01:51 GMT
Here's a fix for this bug. The samples were being correctly written to the PCM buffer. But after the last regular PCM buffer flush the remaining samples were left hanging in the buffer when playback ended. This patch performs one last buffer flush when playback is over.
Comment by Thomas Martitz (kugel.) - Tuesday, 16 June 2009, 07:18 GMT
Won't that delay manual stops? How long are the samples missing?
Comment by Jeffrey Goode (Blue_Dude) - Tuesday, 16 June 2009, 14:30 GMT
In practice, the maximum number of samples that would have to be flushed at the end of playback (including manual stops) is always less than 8704. A manual stop seems to generate a remainder of 7680 samples. That represents just under 1/5 of a second. If this is objectionable for a manual stop, then the buffer length could be forced to 0 when a manual stop is received. I personally don't perceive any delay.
Comment by Jeffrey Goode (Blue_Dude) - Tuesday, 16 June 2009, 15:08 GMT
Looking further into it, it appears that this patch has no effect on a manual stop. This patch merely commits the remaining samples to the end of the buffer, but since playback after a manual stop has already ceased, they're thrown out along with whatever else was buffered ahead. The remaining samples are actually played only when the buffer is completely played out, i.e. at the end of the playlist.
Comment by Jeffrey Goode (Blue_Dude) - Tuesday, 16 June 2009, 15:16 GMT
The play remainder call was moved to the if (playing) block.