Audio pauses and WPS lag?

[epithetless]

Having updated my Sansa e280 from build r20834 to the most recent JPEG-album-art-enabled builds (specifically r20875, r20902, and r20907), I'm finding that audio playback occasionally pauses for a moment after selecting a new song from the file browser, when the buffer is loading. At the same time, the current track time displayed in the WPS momentarily remains static. This seems to happen with themes that display album art (cabbiev2 or BlacknBlue_Glass, for instance), but not ones that don't (e.g. Rockboxed or iCatcher). Has anyone else encountered this?

I have album art stored as "folder.jpg" files in my directories (typically at 500x500 or 600x600 pixel resolutions), but I don't know if that has anything to do with it. When I switch back to r20834, the problem disappears...

[JdGordon]

its probblay expected that .jpg AA is going to take longer than .bmp AA to display... for bmp it only has to scale to fit... for .jpg it has to decompress it first

[froggyman]

would an increased anti-skip buffer help?

[GodEater]

No - it would actually likely make it worse, since there'd be MORE hard drive activity.

[epithetless]

its probblay expected that .jpg AA is going to take longer than .bmp AA to display... for bmp it only has to scale to fit... for .jpg it has to decompress it first

That makes sense. I'll try removing the "folder.jpg" from one of the directories where this happens repeatedly to see if that makes a difference. If not, I'll look into removing the album art coding from the BlacknBlue_Glass WPS, since I actually prefer seeing the extra information it displays.

The thing is, album art is already displayed on the WPS before the audio pauses and playing time lags occur...so I would assume at that point that any JPEG decompression and resizing routines would be done. Is that not the case?

On a different note, would a smaller-sized JPEG take less time/processing power to decompress?

[Lear]

The thing is, album art is already displayed on the WPS before the audio pauses and playing time lags occur...so I would assume at that point that any JPEG decompression and resizing routines would be done. Is that not the case?

No, it loads new album art for each track. (Though it ought to be possible to check if it has already been decoded and if so, just copy it.)

On a different note, would a smaller-sized JPEG take less time/processing power to decompress?

Certainly. But even a bigger file shouldn't cause dropouts like that, I think. Seems like a few more yields() in the code would be in order.

[epithetless]

The thing is, album art is already displayed on the WPS before the audio pauses and playing time lags occur...so I would assume at that point that any JPEG decompression and resizing routines would be done. Is that not the case?

No, it loads new album art for each track. (Though it ought to be possible to check if it has already been decoded and if so, just copy it.)

Yes, but when I'm seeing this problem occur, the album art has already loaded for the particular track I've just selected from the file browser (i.e. it's not the previous track's album art). Things go like this:

- I click on an MP3 from the file browser.
- The screen goes to the WPS, thinks for a brief moment, shows the album art and tag information, and the song starts playing.
- The current track time display stops at 0:01 (the remaining track time also stops) while the song continues to play for a couple of seconds.
- The audio cuts out, and the current and remaining track time displays disappear for a fraction of a second.
- The current track time display reappears at 0:03 or 0:04 (the correct track time), and the audio resumes. The remaining track time display also reappears with the correct time.

It doesn't happen with all (or even most) of my music, but it does consistently happen with certain tracks (meaning I can reproduce it with those tracks every time). For every other track, however, I've noticed that the current and remaining track time displays do blink off for a brief moment within the first few seconds of the song. The problem detailed above, when it occurs with offending songs, appears to be a protraction of whatever causes this blink. Perhaps that might help someone pinpoint a cause...

I did, by the way, manage to completely eliminate the issue (including the relatively minor track time blink) with BlacknBlue_Glass by removing all the album art coding from the theme, so it does seem to somehow be related to the calling/displaying of album art.

[yapper]

Can you post one of your problem tracks somewhere? I haven't seen any of the issues you described.

[Lear]

Yes, but when I'm seeing this problem occur, the album art has already loaded for the particular track I've just selected from the file browser (i.e. it's not the previous track's album art).

Rockbox continues to buffer tracks after starting playback, so it will load album art for the buffered tracks (if the WPS uses album art).

It doesn't happen with all (or even most) of my music, but it does consistently happen with certain tracks (meaning I can reproduce it with those tracks every time). For every other track, however, I've noticed that the current and remaining track time displays do blink off for a brief moment within the first few seconds of the song. The problem detailed above, when it occurs with offending songs, appears to be a protraction of whatever causes this blink. Perhaps that might help someone pinpoint a cause...

Maybe the tracks where it happens have larger album art files?

[pondlife]

Does this mean that the same folder.jpg is actually bufffered/stored for eavh track in a folder?

Ideally, this should be handled internally by buffering.c (i.e. don't reload a file section that's already in memory).

pondlife

[Lear]

Does this mean that the same folder.jpg is actually bufffered/stored for eavh track in a folder?

Ideally, this should be handled internally by buffering.c (i.e. don't reload a file section that's already in memory).

Yes (on both accounts). It doesn't seem that difficult, for album art at least, to locate any previous handle and copy the data...

Still, more yields are probably needed to handle shuffled playback without dropouts.

[MilitantlyUnhelpful]

This turned out to be a lock contention issue. It should be resolved in r20932, please let me know if there are still problems with it. Stalls might still happen at the end of a track, if the next track is not finished loading its cover art yet, as this happens before the track's audio data is buffered.

[epithetless]

Just wanted to report back that r20932 looks to have fixed the audio dropouts and WPS lag. Thanks, MilitantlyUnhelpful!