release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Wiki > Main > AllocatingRAM (compare)

Difference: AllocatingRAM (r2 vs. r1)

Different ways to allocate RAM usage for your feature

Rockbox has a "No Malloc" policy you can read about at WhyNoMalloc but sometimes you really do need to grab some buffer possibly temporarily. This page will explain the different methods available.

Compile-time RAM layout

This list shows the sections in a compiled rockbox.elf, indicating how RAM is allocated at compile-time. The section arrangment is determined by the linker script (firmware/target/arm/as3525/app.lds in this case, for the Sansa e200v2). This varies somewhat between platforms. The interesting parts for memory allocation are audiobuf, codecbuf, and pluginbuf.

SizeNameDescription
32 B .vectors ARM interrupt vectors
460 KiB .text Machine code
102 KiB .rodata Read-only (const) global data
8 KiB .data Global data
8 KiB .stack Stack
384 KiB .bss Global data initialized with zero
5679 KiB audiobuf Audio buffer for audio and/or miscellaneous data
1024 KiB codecbuf Codec buffer for codecs and their data
512 KiB pluginbuf Plugin buffer for plugins and their data
7 KiB .iram Machine code and global data (.icode, .irodata, .idata), in fast IRAM
97 KiB .ibss Global data initialized with zero, in fast IRAM

Allocate on the Heap

This is the easiest way, (i.e add a global variable "static char my_buffer[BUFFER_SIZE]" to your file.c)

Pro:

  • Easy to do
  • available in plugins and codecs (up to the plugin/codec buffer size)

Cons:

  • potentially wastes RAM
  • not nice if the feature isnt common

Allocate on boot up (buffer_alloc(size_t size) )

Next easiest way. call buffer_alloc() in your "init" method and make sure thats calle before playback starts.

Pro:

  • can allocate exactly as much as you need
  • If the feature is disabled no RAM needs to be allocate

Cons:

  • RAM cannot be deallocted or resized
  • Playback must be stopped to allocate more

Steal a Buffer

Temporarily steal the talk/plugin/audio buffer, each has its own size and cons...

Talk buffer ( talk_buffer_steal() )

Plugin Buffer ( plugin_get_buffer() )

Pros:

Cons:

  • cannot start a plugin while the buffer is stolen
  • the remaining buffer may not be large if a pluign is already running

Audio Buffer ( plugin_get_audio_buffer() )

Pros:

Cons:

  • playback needs to be stopped, but you can have up to ~30Mb on some targets

dynamic allocation like "malloc()" (bufalloc())

Most frowned-on method of allocation, use this carefully... The buffer is allocated as a handle in the playback buffer and could be moving around the buffer as playback advances.

Pro:

  • free/resize able
  • playback doesnt need to be stopped

Cons:

  • the buffer may move, so you HAVE to call bufgetdata() to use the buffer
  • might fail if there is no room on the playback buffer

r4 - 28 May 2011 - 01:30:28 - SeanBartell

Revision r2 - 28 Mar 2011 - 23:39 - SeanBartell
Revision r1 - 03 Aug 2008 - 02:09 - JonathanGordon
Copyright by the contributing authors.