FS#12147 - Assigns bigger IRAM for libtremor

Attached to Project: Rockbox
Opened by Sei Aoyumi (Aoyumi) - Friday, 03 June 2011, 20:20 GMT
Last edited by Nils Wallménius (nls) - Monday, 06 June 2011, 13:28 GMT
Task Type Patches
Category Codecs
Status Closed
Assigned To No-one
Operating System Sansa AMSv2
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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]
This task depends upon

Closed by  Nils Wallménius (nls)
Monday, 06 June 2011, 13:28 GMT
Reason for closing:  Rejected
Additional comments about closing:   FS#11268  was committed which means this patch is not needed.
Comment by Sei Aoyumi (Aoyumi) - Friday, 03 June 2011, 20:22 GMT
Upload patch.
Comment by Dominik Riebeling (bluebrother) - Sunday, 05 June 2011, 11:08 GMT
Please update your Flyspray profile to include your real name. We have a real name policy.
Comment by Sei Aoyumi (Aoyumi) - Sunday, 05 June 2011, 14:52 GMT
ok, I updated profile.
Comment by Andree Buschmann (Buschel) - Sunday, 05 June 2011, 16:26 GMT
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().
Comment by Nils Wallménius (nls) - Sunday, 05 June 2011, 19:41 GMT
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