Metadata-on-Buffer testing

Introduction

NicolasPennequin's MetadataOnBuffer SummerOfCode2007 project to revise the buffering side of playback has now produced a largely-working build. His code is hosted in git, and a snapshot of the latest is available from http://repo.or.cz/w/Rockbox.git?a=shortlog;h=mob

Before this is committed, it needs lots of testing. SWCODEC-using volunteers are wanted. If you can find a reproducible bug that doesn't happen with SVN Rockbox (or an intermittent bug that doesn't seem to happen with SVN) then please add recipes/details below.

---

Reproducible issues

White noise, crashes and other badness after enabling crossfade during playback

1. Configure crossfade as "Disabled / 0 / 0 / 1 / 1 / Crossfade".
2. Start playback.
3. During playback, go into settings and enable crossfade.
4. Playback stops (it should stop and restart, but that's a bug in SVN too).
5. Press PLAY to restart playback, then skip forward one track.

Expected result: Playback continues.

Actual result: Occasionally a burst of white noise is played, this can vary in length but might be as long as 2 seconds. (GodEater reports that this crashes his iPod Video instead.)

Last tested with commit: 23 Oct 2007 - "Makes some variables const and some others volatile"

---

Intermittent issues

---

Fixed issues

We'll keep these around for regression testing...

Reshuffle playlist doesn't work

1. Start playback with a playlist of known order (database will give alphabetical order)
2. From the WPS context menu, select Playlist > Reshuffle

Expected result: The playlist is reshuffled, any displayed next track name/info is updated (perhaps after a short delay).

Actual result: The reshuffle takes place (as can be seen by viewing it), but all buffered tracks are played in the original order, and next track info is not updated.

Last tested with commit: 22 Oct 2007 - "Close partially buffered handles when changing tracks "

Status: Fixed.

Crash when skipping backwards via playlist

1. Generate large playlist using the database
2. Start playback some way down the playlist.
3. From the WPS context menu, select Playlist > View Current Playlist
4. Repeatedly move up by one entry and press SELECT.

Expected result: At each press of SELECT, the previous track should be played (perhaps after a short delay for buffering).

Actual result: After several repetitions of step 4, the player locks hard.

Last tested with commit: 22 Oct 2007 - "Close partially buffered handles when changing tracks "

Status: Fixed.

Hard crash with long tracks buffered

1. Set up a directory with just two long tracks (in my case, two MP3s of 20:35/10183KB and 20:35/16MB).
2. Select the first track.
3. Once playback has started, press RIGHT to skip to the next track.
4. After a bit of track 2 has played, press LEFT twice to skip back to track 1.
5. Press SELECT to return to the file browser.

Expected result: Browsing is possible while playback continues.

Actual result: The device locks up before returning to the browser.

Last tested with commit: 22 Oct 2007 - "Close partially buffered handles when changing tracks "

Status: Fixed.

Progressbar loses sync in the last seconds of a track

1. Play a series of short tracks (e.g. 4 seconds) with crossfade disabled.

Expected result: The progress bar runs smoothly to the end of each track.

Actual result: The progress bar resets to 0:00 a couple of seconds before the end of the track. It is synced with the codec, not with the WPS.

Last tested with commit: 22 Oct 2007 - "Close partially buffered handles when changing tracks "

Status: Fixed.

The problem is that while the track is finishing to be played (PCM buffer emptying), the playback code has already moved to decoding the next track. To update the progressbar at this time, pcmbug_get_position_callback() is called in an interrupt to increment the "elapsed" value of the previous (which is still current for the user) track's ID3 info. In the MoB code, pcmbug_get_position_callback() is disabled and can't be adapted to work the same way as before. A better implementation is needed. jhMikeS has suggested adding timestamps to the PCM buffer.

Buffer is not refilled if user spins up disk

1. Start playback (with a playlist that will not all fit in the buffer!)
2. Wait (or skip) until the buffer is only a third full (as per the buffering debug screen).
3. Load a demo plugin (e.g. snow) to force the disk to spin up.
4. Check the buffer level again in the debug screen.

Expected result: The buffer has refilled.

Actual result: No refill is triggered.

---

Related links

• SoftwareCodecPlayback
• BufferingAPIProposal
• RockboxPCMPlayback