Rockbox Development > Feature Ideas
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:
--- Quote from: pabouk on September 30, 2010, 02:17:05 PM ---
--- Quote from: saratoga on September 29, 2010, 08:04:50 PM ---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.
--- End quote ---
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.
--- End quote ---
You understand incorrectly.
torne:
--- Quote from: pabouk on September 30, 2010, 02:17:05 PM ---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.
--- End quote ---
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.
--- Quote from: saratoga on September 29, 2010, 08:04:50 PM ---Where the heck did you get the idea you needed a colon? It should probably be fixed.
--- End quote ---
--- Quote from: pabouk on September 30, 2010, 02:17:05 PM ---Saratoga, please read it more carefully, especially the last part of the comment - start on the third line from the end.
--- End quote ---
* 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 >.>
--- Quote from: Llorean on September 29, 2010, 11:27:45 PM ---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.
--- End quote ---
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.
--- Quote from: dreamlayers on September 29, 2010, 09:02:21 PM ---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.
--- End quote ---
Logic!? How dare you! ;D 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.
--- Quote from: jimbilly on September 30, 2010, 03:47:56 PM ---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
--- End quote ---
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.
--- Quote from: torne on September 30, 2010, 04:25:02 PM ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version