Rockbox Development > Feature Ideas
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. :D
saratoga:
--- Quote from: CowonFTW on September 29, 2010, 12:09:22 PM ---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?
--- End quote ---
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:
--- Quote from: CowonFTW on September 29, 2010, 12:09:22 PM ---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?
--- End quote ---
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?
--- Quote ---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. :D
--- End quote ---
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!
--- Quote from: saratoga on September 29, 2010, 12:17:59 PM ---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.
--- End quote ---
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.
--- Quote from: torne on September 29, 2010, 12:35:39 PM ---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?
--- End quote ---
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?
--- Quote from: torne on September 29, 2010, 12:35:39 PM ---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.
--- End quote ---
Indeed. :P It's just naming conventions, I'll adapt, it's just confusing at first is all.
saratoga:
--- Quote from: CowonFTW on September 29, 2010, 02:10:40 PM ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version