faster AA?

[jimbilly]

I did a little testing on this,  i find very little lag(fraction of a second) with jpg AA at 500x500 when skipping tracks

but,  with crossfade on i get multisecond delays ,  probably busy crossfading, then it gets around to the AA display??

cowonfta, do you have crossfade enable by chance?  if so, test without to compare

[saratoga]

Its a comment that lists all the places album art can be searched, same as the ones in the manual.  Actually looking at it none of them have the colon in it you mentioned above, nor do the wiki or manual.  Where the heck did you get the idea you needed a colon?  It should probably be fixed.

Saratoga, please read it more carefully, especially the last part of the comment - start on the third line from the end. If I understand it correctly the colon character acts as a switch so it is not a necessary part of a filename with size specified.

You understand incorrectly.

[torne]

Regarding the speed of displaying AA: I think the biggest delay is caused by loading, decoding and displaying the image. This problem could be solved by pre-loading and pre-decoding the next image in advance. I.e. you would have the current image displayed and the next one prepared in RAM. Unfortunately it will require more RAM.

We already do load and decode the image in advance, not just the next one but for every single track in the buffer. When the actual track change happens, it literally just has to copy the data directly to the screen buffer. That's why I asked the original poster for more information about what they mean by delay, which they haven't answered. You can see this quite easily by looking at the disk accesses: just queue up a playlist with lots of different albums in it, and you'll see that it doesn't need to access the disk when tracks change, even if the art is different. JPEG decoding, any resizing, etc all happen at the time that the art is loaded into the buffer, so having JPEG art or art that's the wrong size makes *buffering* take longer, but has no effect on playback.

Edit:
As jimbilly mentions, it's likely that some option you have enabled needs lots of CPU time, at the time of track change: crossfading is one possibility. This delays the WPS code actually updating the screen for the new album art...

Edit 2:
One more thing: you asked what the thing with the colon on the size string is; this is just a hack used by pictureflow. It has nothing to do with album art loading on the WPS, which always passes a size string which looks like ".100x100" depending on the size of the album art viewport on the WPS. It has nothing to do with the filenames, it's determined by the code asking for the art.

[CowonFTW]

This will be long I'm answering everyone at once.

Where the heck did you get the idea you needed a colon?  It should probably be fixed.

Saratoga, please read it more carefully, especially the last part of the comment - start on the third line from the end.

 * If the first symbol in size_string is a colon (e.g. ":100x100")
 * then the colon is skipped ("100x100" will be used) and the track
 * specific image (./<trackname><size>.bmp) is tried last instead of first.

!! Thought I having a 'twilight zone' moment, no one was seeing what's right there in plain sight! But torne says it's only for Pictureflow, so nevermind, moving on >.>

Wouldn't the problem be the aforementioned "large" images? Just don't put ridiculously large album art on your player with the filename Rockbox is going to look for first, and you don't have to wait for the resize.

Your insistence that Rockbox "co-exist" with the way the original firmware wants files is your problem, not Rockbox's which is, as described, a "replacement" firmware not a "supplemental" firmware.

^{Whiskey Tango Foxtrot??}

Uh... yeah. I just want to understand how I can minimize the ridiculously large delay/lag/buffering/whatever from the time a track change occurs until AA is displayed, to as near realtime as possible. So in relation to AA processing, using a size-as BMP will invoke the least amount of processing, correct? I'm testing the option of going with ./<albumtitle>.bmp structure as it's #2 in the comparator stack, bypassing both JPGs. I am only going to change the code around if it proves to contribute to the delay, but that seems less likely than previously thought.

I don't think that the search is significantly slowing down album art.

Maybe do a test.  Comment out the searching, leaving just one option.  Maybe even alter the code so there is only one single album art file which is loaded for every album.  Then see if things are faster that way.

Logic!? How dare you! I did just that. I don't know how fair the test was to the JPG scaling as I only setup ./<albumname>.bmp for 25 albums. But yes, as forecast, there's negligible delay using BMPs. In track-hopping quickly as possible, depending on theme, some times that ? 'no aa' image flashes up for a split-second with cover.jpg, and it shows up more frequently and stays on-screen longer with Folder.jpg. Deductive reasoning says bypassing the JPG decoding and scaling routines will net a speed increase. (FYI certain themes will not show AA when they are BMPs. Perhaps another thread.)

I have yet to test if the search order has any significance to the delay. I also want to test using a same-size JPG vs. BMP to determine how much of the delay is related to JPEG decoding.

I did a little testing on this,  i find very little lag(fraction of a second) with jpg AA at 500x500 when skipping tracks

but,  with crossfade on i get multisecond delays ,  probably busy crossfading, then it gets around to the AA display??

cowonfta, do you have crossfade enable by chance?  if so, test without to compare

No crossfades anywhere. Not even backlight. And, uh -- we are talking about just a fraction of a second! But I think I have it as fast as it's going to get without a large commitment to code refactoring.

You can see this quite easily by looking at the disk accesses: just queue up a playlist with lots of different albums in it, and you'll see that it doesn't need to access the disk when tracks change, even if the art is different. JPEG decoding, any resizing, etc all happen at the time that the art is loaded into the buffer, so having JPEG art or art that's the wrong size makes *buffering* take longer, but has no effect on playback.

My player accesses disk both at track start and track end for 3-5 seconds, buffering I guess? Some track changes it does not, but most of the time it does. I only use flacs so it's probably related to files being 40M/ea instead of 4M/ea? I would think there's more SRAM to buffer than that. I haven't investigated how the playlist cachecontrol actually works, but yes it's obvious in what order things go, even w/o AA, like using rockbox_failsafe WPS - you see the text change and track counter increment before any audio spits out.

To that end, it's all the same "lag" to me. Lag, buffering, tomato, tomato. If the AA takes 250ms longer for whatever reason, than that pushes everything else back too, and the gap between tracks becomes 250ms wider, sequential events being, uh sequential. Also some themes are just badly designed WRT a responsive interface. AluminArt for example, this takes a huge amount of time on the D2, over a second using pre-scaled BMPs. Hopping on scan between tracks I feel like the player is going to crash, it feels so bogged down. So had I been using a more efficiently written WPS in the first place, perhaps this thread wouldn't have been created. Now I know that "faster AA?" has many factors.

Anyway - it's not perfect but it's perfect enough. I'm going with a full scale ./<albumname>.bmp test, since it meets both criteria - JPEGs can remain and AA is displaying faster. I'll post my test results, but I think we're done here.

Thanks for participating in such a trivial thread, you guys rock!

[Llorean]

Basically, if you use songs that actually fit on the buffer (so, not FLAC or other lossless) the album art will be pre-decoded and ready by the time the next track loads. In fact, if you just wait for the next track to progress "naturally" it will be to.

The only reason you're running into a problem is because skipping tracks to one not buffered requires loading the song, loading the album art, decoding the album art, then displaying it. These things will always take time, especially the decode.

You've basically created the most sub-optimal situation for album art possible, and then you're talking about a delay in milliseconds. For many users (myself included) the album art display is literally instant (unless we skip forward many songs) because we use lossy audio formats.

[torne]

Okay, I understand what your problem is now, and the issue is more complicated than any explanation posted by *anyone* including you, I think. (Edit: Llorean also explained it while I was typing this

First, stepping back a little, I'm going to explain a simplified version of how buffering works including album art buffering, because you seem to be under the impression that buffering time is related to lag and it's not. So, with an example (I am leaving out several steps here which are not relevant to the present discussion, so please, nobody take this as an authoritative description of buffering):

When you start a playlist with ten tracks in it, all from different albums with their own album art, buffering starts. For each track it does a bunch of steps: first it loads the metadata for the track (so that things can display the titles/etc of the upcoming tracks), then it searches for the album art using the code you already looked at. Once it finds the album art file it calls the bmp loader if it's a bmp, or the jpeg loader if it's a jpeg. Both image loaders store the album art in the buffer in uncompressed bitmap form, scaled to the correct size for your WPS - the bmp loader only has to resize the data, the jpeg loader has to decode the jpeg as well. After the album art, the next thing to be buffered is the actual file. If there is enough memory to buffer the entire file to the end, it will then repeat these steps for the second track, then the third, and so on until it fills all of the available memory. Once memory is full, buffering stops.

When most of the data in memory has been "used up" by playback (typically "all but 5 seconds' worth"; this can be adjusted and it's supposed to be "long enough to do another cycle of buffering") then buffering starts again, carrying on from where it left off and overwriting all the data that was previously buffered up to the current point being used by playback. This way, the maximum interval between disk accesses is achieved.

There are several consequences of this:
1) The behaviour with respect to the *first* track is sometimes odd/slow because it is buffering the data at the same time as it's trying to actually decode/display/play it.
2) When a new track starts by the "natural" progression of playback, the album art only needs to be copied from one place in ram (the audio buffer) to another (the display buffer). On some players there is a second step to actually update the screen, depending how the display buffer works on that hardware. This step takes a constant amount of time, is the point; the art is already found, loaded, decoded and resized.
3) If you skip tracks, or insert new tracks into the playlist to be played next, it's possible to run out of buffered data, because you have advanced the playback position past the current end of the buffer. In this case any in-progress buffering operation is abandoned and it starts over as if it was a new playlist.

You're using FLAC, which I didn't notice (or you didn't mention, doesn't matter) until now. FLAC files are obviously much bigger than lossy compressed audio, so the same amount of available buffering memory can store much less actual audio; probably less than one complete track most of the time. The problem with this is that *every* time you skip a track, you are provoking 3) above: it's having to give up and rebuffer everything. There is a noticeable lag caused by this even when *no* album art is involved, just because it has to start buffering the actual audio from scratch.

This is what nobody realised was the problem; your use case is not the "usual" one of natural playback advancement, or the "other usual" one of lossy audio where skipping one or two tracks doesn't cause a rebuffer. So yes, for your use case here, the time it takes to find, decode and resize the image data *does* directly contribute to a delay in the time until the album art is visible. If the album art is a prescaled bitmap then it will definitely load faster, as you have found, in this case (though it will make no difference to the "normal" case where the art has been buffered in advance, which is true even for your large flac files - the size of the files only affects matters here if you skip tracks).

However, there is still basically zero chance that changing the search order will result in even a single millisecond being saved here; as has already been explained, the checks will take a couple of microseconds maybe. Having the art be a bitmap that's already the right size is the best you can do. If you want it to be faster than that, then you will need to actually optimise the code in Rockbox in a more fundamental way: speed up disk accesses on your target, or speed up bitmap loading itself, or change the sequence of events that the playback code goes through when it's forced to load unbuffered data after a track skip. None of these are easy

[soap]

I only use flacs so it's probably related to files being 40M/ea instead of 4M/ea? I would think there's more SRAM to buffer than that.

No, you don't even have 40MB of RAM.


I have a theory that some Original Firmwares "cheat" by buffering the first few seconds of the next few tracks, regardless of if the current track itself can fit entirely in RAM.

This would increase perceived responsiveness at the cost of efficiency.