Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Codecs
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Next release
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by nls - 2010-05-13
Last edited by nls - 2011-06-06

FS#11268 - Optimization for tremor on targets that don't use iram.

Some of our targets don’t use iram sections as most do, in tremor we assume that all targets use iram so these targets do the same copying etc. that targets with a little iram do (due to that being the default case in the preprocessor logic.

This patch inserts #ifdef USE_IRAM around the iram specific parts especially avoiding the vector copy in block.c. This speeds up decoding on the gigabeast about 2MHz across the test set.

I’m not entirely confident that i understand the logic in the memry handling so i would apreciate reviewing of the changes.

Other targets that should see a speedup are gigabeat f/x and the ams targets with little ram that have the codec buffer entirely in iram (clip at least).

Closed by  nls
2011-06-06 13:28
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

committed

nls commented on 2010-05-14 08:27

Hmm, this seems to *sometimes* cause a sim to output garbled sound… Usually the first track is fine but if i skip back to the beginning the sound sometimes becomes messed up.
any ideas about that?

nls commented on 2010-05-17 13:08

This fixes the garbled sound but still causes crashes on trackchange sometimes, probably something in the cleanup that goes wrong.
Of course just setting IRAM_IBSS_SIZE to be large enough to hold the double buffer in “iram” works but it doesn’t give as large speedup.
Anyway, this patch turns tremor into a bit more of an #ifdef mess so i would like suggestions how to make it cleaner.
Also if anyone knows why, in vorbis_synthesis_blockin prevCenter is different if the iram double buffer is used.

nls commented on 2010-05-17 20:04

This patch seems to fix the crash in the sim, (was freeing the wrong pointer) but it seems to still have the
bug where the sound becomes garbled after skipping back to the beginning of a song. Sometimes i need
to do it 10 times to trigger the bug, sometimes less :/

I know this code pretty well, as most of it came from one of my tremor patches, so I could take a look. I know exactly why prevCenter is different if the iram double buffer is used.
What is the main intention here - use more of the Gigabeast’s ram to avoid having to do the memcpy in the blockin code? (does Gigabeast have larger plugin buffer than other targets?). The fact its garbled suggests the pointers are not being reset properly on reinit. The code is admittedly a bit of a spaghetti bowl.

nls commented on 2010-05-24 08:39

Yes, tremor currently pretends to have iram buffers with the same size as on targets with 96k on targets that don’t use iram at all.
As you say this leads to copying between the “iram” buffer and the dram one which is completely useless when the “iram” buffer is not in iram.
Benchmarking on the beast shows that this saves about 2MHz or about 5-7%
AFAIU it shouldn’t use any more ram than currently as the static buffer is gone and the malloc()’s that are now used as fallbacks when
the iram buffer is full should be used always, it works but there is that sound garbling bug i’ve gotten on the sim… I found one bug with the fallback malloc, v→first_pcm is never freed (though this should not happen currently since all targets use the static “iram” buffer)
Another approach that would probably work better but is slightly hacky is to just pretend to have more iram so the static buffer is
large enough to avoid the copy, should be a less intrusive change too.

Not only the gigabeast is affected, the gigabeat f/x don’t use iram either and the clip has the entire codec buffer in iram so it doesn’t use
it in the traditional way either.

I would be happy if you took a look and commented on the patch.

nls commented on 2011-06-05 22:34

Found and fixed the bug so this should now be good for commit. I’ll run some tests tomorrow.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing