Rockbox

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

FS#12147 - Assigns bigger IRAM for libtremor

This patch assigns bigger IRAM for libtremor in as5325 and as3525v2.
Typically decoding speed around 10% are improved.
I perform a check only in as3525v2(Clip+).

Probably the operation check with other models will be necessary, too.

[For SVN revision 29934]

Closed by  nls
2011-06-06 13:28
Reason for closing:  Rejected
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

 FS#11268  was committed which means this patch is not needed.

Upload patch.

Please update your Flyspray profile to include your real name. We have a real name policy.

ok, I updated profile.

First your report was a bit of a mistery because on as3525 targets the codecs are fully loaded to IRAM. But after some discussion in IRC the effect is understood: Before your patch the codec assumes it only has a small amount of IRAM available which can be allocated via iram_malloc(). As a result the allocation of a special in the decoder failes and _ogg_malloc() was used instead. For normal targets using smaller IRAM it is faster to do some additional memcpy()-operations to optimally use the small IRAM. On targets with large IRAM this is not required and slows down the codec. The as3525 targets – before your patch – use a configuration where everything is IRAM but the codec does not know. Hence the codec will still use additional – but obsolete – memcpy()-operations. Your patch simply let’s the codec know the IRAM is large enough and therefor avoid the additional memcpy().

nls commented on 2011-06-05 19:41

I’m looking at solving this in a nicer way for targets where separate iram buffers makes no sense either because they don’t have iram or because they have the codec buffer entirely in iram. See  FS#11268 

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing