Rockbox

Tasklist

FS#12077 - No mallocs in libfaad

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Friday, 22 April 2011, 02:10 GMT
Last edited by Andree Buschmann (Buschel) - Sunday, 24 April 2011, 20:29 GMT
Task Type Patches
Category Codecs
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.8.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The attached patch removes malloc from the libfaad codec. The patch works fine on simulation with several AAC and AAC-HE files. It compiles and links for iPod Video and LogikDax (lowmemory target). No test runs on targets o far.

What has been done:
- Replace malloc() with static buffers.
- Remove free().
- Set several defines (MAX_CHANNELS, MAX_SYNTAX_ELEMENTS) to reasonable values to limit the memory consumption

What needs to be done:
- Cleanup (I think one or two arrays might not be needed anymore).
- Test and maybe some performance tweaking on targets

This task depends upon

Closed by  Andree Buschmann (Buschel)
Sunday, 24 April 2011, 20:29 GMT
Reason for closing:  Accepted
Additional comments about closing:  Submitted with r29778.
Comment by Andree Buschmann (Buschel) - Friday, 22 April 2011, 08:51 GMT
Could remove a 8 KB array (s_fb_intermed) as this was not used anyway, the pointer was overwritten in the codec.

Interesting option after rework: In apps/aac.c and raac.c there are 2 large IRAM arrays defined which are used set to time_out[] and fb_intermed[] in the decoder. The array used for fb_intermed[] can be moved to the decoder library itself and removed in the codec. The array used for time_out[] is problematic: AAC-decoding needs an array size of [2][1024], AAC-HE needs [2][2048]. This array is significant for speed and should therefor be located in IRAM, but there is only enough IRAM for [2][1024] even on targets with larger amount of IRAM. Current solution: A [2][1024] array (gb_time_buffer) is located in IRAM, an additional [2][2048] array (s_time_buffer) is located in RAM. The codec decides if IRAM or RAM can be used. As a result the decoder has [2][1024] = 8 KB of unused IRAM when decoding AAC-HE.
Possible solution: Define generic buffer in IRAM (similar to what malloc did) and decide how to use it depending on AAC/AAC-HE.
Comment by Andree Buschmann (Buschel) - Friday, 22 April 2011, 12:32 GMT
Moved allocation of time_out[] and fb_intermed[] from apps/codecs to libfaad. Now we have an decodeer-internal solution.
Comment by Andree Buschmann (Buschel) - Friday, 22 April 2011, 16:35 GMT
Three changes:
- Declare qmfs/qmfa direclty in sbr-type, do not use static declarations for those arrays anymore.
- Remove all unneeded _init() and _free() functions.
- Add formerly unused NeAACDecPostSeekReset() to apps/codecs/aac.c
Comment by Andree Buschmann (Buschel) - Saturday, 23 April 2011, 16:49 GMT
Same as v11, but I introduced the define FAAD_STATIC_ALLOC (libfaad/common.h) to be able to switch from static to dynamic allocation for AAC-HE related data arrays. Those sum up to ~123 KB for SBR + PS.

Reason for this is that static allocation of those arrays will use this memory always. For AAC-LC files this memory is wasted and will reduce the amount of memory available for m4a tables. This might impact the maximum length of files to be able to play.
Comment by Andree Buschmann (Buschel) - Saturday, 23 April 2011, 22:29 GMT
static police...
Comment by Andree Buschmann (Buschel) - Sunday, 24 April 2011, 10:47 GMT
Allocate the buffer variables X_left/X_right (now part of the struct XLR) via malloc(), if FAAD_STATIC_ALLOC is not set. This lets the decoder save ~40 KB when decoding AAC-LC files and gives more headroom for the m4a tables of long files.
Only exception: XLR fits into IRAM, in this case always allocate statically. The advantage in speed is ~10 MHz on a nano 2G.
Comment by Andree Buschmann (Buschel) - Sunday, 24 April 2011, 14:08 GMT
Resync against r29773.

Loading...