Rockbox Development > Feature Ideas

faster AA?

<< < (5/5)

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:

--- Quote from: CowonFTW on October 01, 2010, 10:25:04 AM ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[*] Previous page