faster AA?

[CowonFTW]

Hi.

Using Cowon D2 there's this lag when AA is used, it's 100ms or so. (guess. Haven't put in any counters), Is this from the tag lookup or the resize or JPEG decoding or all the above or something else entirely?

My thinking is a current directory static filenames setup is probably the fastest way as there's no id3-> tag compares just an if. Something obvious like .rbaa<size>.bmp. Yes?  Is it worth the #1 search position in albumart.c? Would the speed increase be noticeable to human eyes?

Thanks.

Sidenote, since ID3 tags in flacs is considered wrong, from my newbieness with the code it looks like flac metadata is being parsed properly and just stored in variables labelled for ID3? It's kind of confusing.

[saratoga]

My thinking is a current directory static filenames setup is probably the fastest way as there's no id3-> tag compares just an if. Something obvious like .rbaa<size>.bmp. Yes?  Is it worth the #1 search position in albumart.c? Would the speed increase be noticeable to human eyes?

We already support that.  Take a look at the album art wiki page.  If you don't want to decode/resize at playback you can do it in advance. 

[torne]

My thinking is a current directory static filenames setup is probably the fastest way as there's no id3-> tag compares just an if. Something obvious like .rbaa<size>.bmp. Yes?  Is it worth the #1 search position in albumart.c? Would the speed increase be noticeable to human eyes?

Any time taken by searching is nothing to do with tags: it already has the metadata for the track loaded, so it doesn't take measurably more time to construct "ArtistName-AlbumName.bmp" or whatever than it does to construct a fixed name like folder.jpg. The searching time is entirely dominated by the time it takes to check for the existence of each file on disk, which may be slow if you don't have the directory cache enabled. If you have the directory cache enabled, the checks for the existence of the files are also very quick.

This is probably not the reason behind the problem you are having, in summary. When you say "lag", what do you mean? Between the track starting and the album art appearing on the WPS, or something else? Does the audio keeps playing fine, or does that stop too?

Sidenote, since ID3 tags in flacs is considered wrong, from my newbieness with the code it looks like flac metadata is being parsed properly and just stored in variables labelled for ID3? It's kind of confusing.

Originally Rockbox only supported MP3 playback, because it ran on a device with hardware MP3 decoding. Thus, the metadata system was originally written just for ID3, and when it was extended to support other metadata formats the names were left alone.

[CowonFTW]

Hi. Thanks for the fast replies!

We already support that.  Take a look at the album art wiki page.  If you don't want to decode/resize at playback you can do it in advance. 

Yep. Not from the wiki page but from the bool search_albumart_files stack of if conditionals. I was thinking that, considering we're talking about 200MHz ARM9 in a Telechips IC, even such simple things might contribute milliseconds here and milliseconds there, just want to make it instantaneous if possible.

Also, and this should have been part of the initial post, I wanted to add it to the top of the filecheck block, not only for only having to perform one compare, but because of existing Folder.jpgs and cover.jpgs that are large as far as Rockbox is concerned. (1600x & 600x, respectively) These would be detected and acted upon before the existing alternate scenarios, except for the per-filename method which, considering we're on FAT32 and can't have symlinks, would be wasteful.

This is probably not the reason behind the problem you are having, in summary. When you say "lag", what do you mean? Between the track starting and the album art appearing on the WPS, or something else? Does the audio keeps playing fine, or does that stop too?

Directory Cache is enabled. No, everything works fine. It's just this - lag, latency, pause - when album art is loading/displaying. I've tried different WPSs to make sure it wasn't just someone's inefficient theme. As I said it's roughly a tenth or eighth of a second, it's just that it's not "snappy" feeling. I cringe at using a sentence beginning with "with the original firmware..." --- HOWEVER...

The place it's most obvious is shuffling and rapidly skipping tracks. It starts to feel sluggish, like it's having trouble keeping up. I have the Virtual LED on and it's solidly lit doing this, never flickers, which is weird because I would have said that there's no way it's the media. (Using a Class10 Sandisk Extreme that cost more than the player, one of the fastest made!)

I guess the main problem is having expectations. Having used a D2 for 3 years, I have a preconceived notion of how responsive the UI should behave, so if it's not at least that "fast" then it's "slow" - not sure if I'm explaining that well. I hate getting OCD over something trivial, and I do apologize. Do you think there's any hope for a speed increase?

Originally Rockbox only supported MP3 playback, because it ran on a device with hardware MP3 decoding. Thus, the metadata system was originally written just for ID3, and when it was extended to support other metadata formats the names were left alone.

Indeed. It's just naming conventions, I'll adapt, it's just confusing at first is all.

[saratoga]

Yep. Not from the wiki page but from the bool search_albumart_files stack of if conditionals. I was thinking that, considering we're talking about 200MHz ARM9 in a Telechips IC, even such simple things might contribute milliseconds here and milliseconds there, just want to make it instantaneous if possible.

200MHz means 200 million cycles per second.  So one millisecond is 200,000 cycles.  It doesn't take 200,000 cycles to evaluate an if.  More like 2 on average. 

[CowonFTW]

Rb's kernel is that efficient? Hallelujah!

Hmm. OK.

I was trying to do some quick speed testing by renaming all Folder.jpg & cover.jpg files and converted them all to .rockbox/albumart/<artist>-<albumname>:<size>.bmp, but uh, I'm stuck, you cannot make a : part of a filename on a FAT32 filesystem. This will need to be changed. Should I file a bug report?

[gevaerts]

I'm stuck, you cannot make a : part of a filename on a FAT32 filesystem. This will need to be changed. Should I file a bug report?

No. Reading the relevant part of the manual should be sufficient.

[jimbilly]

hmm...

my manual says:
5.   /.rockbox/albumart/albumartist-albumtitle.{jpeg,jpg,bmp}



why not just rename all your large AA as folder.jpg then create the small versions as cover.bmp which is supposed to be higher in the search order.

[saratoga]

Rb's kernel is that efficient? Hallelujah!

Branches are handed by the decode logic on the processor, not by software.  Rockbox doesn't have efficient branches, it runs on processors that only take a few cycles to compute a branch.

In other words branches are quick because your processor is simple, and simple processors have fast branches.

I was trying to do some quick speed testing by renaming all Folder.jpg & cover.jpg files and converted them all to .rockbox/albumart/<artist>-<albumname>:<size>.bmp, but uh, I'm stuck, you cannot make a : part of a filename on a FAT32 filesystem. This will need to be changed. Should I file a bug report?

http://download.rockbox.org/daily/manual/rockbox-sansafuzev2/rockbox-buildap2.html#x17-374000B.20

[CowonFTW]

hmm...

my manual says:
5.   /.rockbox/albumart/albumartist-albumtitle.{jpeg,jpg,bmp}

why not just rename all your large AA as folder.jpg then create the small versions as cover.bmp which is supposed to be higher in the search order.

No, that's unacceptable. Rockbox must co-exist properly with both the host machines and the player's stock firmware. Both Folder.jpg and cover.jpg will remain.

No. Reading the relevant part of the manual should be sufficient.

Could you please explain this code block from from albumart.c ?

/* Look for the first matching album art bitmap in the following list:
 *  ./<trackname><size>.{jpeg,jpg,bmp}
 *  ./<albumname><size>.{jpeg,jpg,bmp}
 *  ./cover<size>.bmp
 *  ../<albumname><size>.{jpeg,jpg,bmp}
 *  ../cover<size>.{jpeg,jpg,bmp}
 *  ROCKBOX_DIR/albumart/<artist>-<albumname><size>.{jpeg,jpg,bmp}
 * <size> is the value of the size_string parameter, <trackname> and
 * <albumname> are read from the ID3 metadata.
 * If a matching bitmap is found, its filename is stored in buf.
 * Return value is true if a bitmap was found, false otherwise.
 *
 * 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.
 */

And most specifically:

if (*size_string == ':')
    {
        size_string++;
        track_first = 0;


I did not make this up, nor write this code, and since the whole point is to lessen the compare interval to it's shortest time possible thought it relevant that it skip the per-file search...

Thanks for reading.

edit: mouth too big

[saratoga]

No. Reading the relevant part of the manual should be sufficient.

Could you please explain this code block from from albumart.c ?

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.

I did not make this up, nor write this code, and since the whole point is to lessen the compare interval to it's shortest time possible thought it relevant that it skip the per-file search...

I think you should start out trying things a little easier before diving into album art.  Once you get the hang of c this will probably make more sense.

[dreamlayers]

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.

[Llorean]

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.

[torne]

since the whole point is to lessen the compare interval to it's shortest time possible thought it relevant that it skip the per-file search..

There are two reasons why this doesn't make sense, one of which has already been explained.

1) The search takes probably *microseconds*. I would be surprised if it added up to even one millisecond. So, trying to optimise it is a waste of time.

2) The search is done at the time the track is *buffered*, not when it starts playing. Album art is buffered in advance just like the actual track data, so the search can't be causing a lag at the time it plays.

[pabouk]

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.

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.