Hi Marko,
Why exactly do you need exact RAM values? Can't you just measure it?
Note also that if your compiler supports C99-style variable-length
arrays (gcc does), then the best is to define VAR_ARRAYS. Otherwise, you
should probably use alloca (USE_ALLOCA). Do not use the global stack
(that requires GLOBAL_STACK_SIZE) unless all else fails.
Other than that, I would tend to suggest just *measuring* the memory
use. It should be more reliable than any estimate I give you. Note that
the _create() calls are the only ones allowed to allocate heap memory,
so the only thing you need to need to be careful with is the stack. And
even that should be mostly the same from one call to the next (just make
sure you exercise the PLC).
Cheers,
Jean-Marc
On 10-12-01 05:44 AM, celt wrote:> ?
> hi ?Jean-Marc,
>
> thanks for your answer.
> But still I am struggling to find a reasonable upper limit for the RAM
> sizes.
>
> You say we need 4.5/9.0 kB for enc/dec per channel.
> But are those sizes really independent of any settings, like frame_size,
> bitrate, complexity, etc. ?
>
> at least in our configuration I find these requirements:
> - native stack: < 2.1kB (enc or dec) measured by RealView Profiler
> - heap: (summing up the celt_alloc calls):
> mode_create: 2430
> enc_create: 10284
> dec_create: 17568
> - GLOBAL_STACK_SIZE:
> not sure! (default = 100k ???)
> 2k is not enough, 5k is ok.
>
> our config:
> - version = 0.9.1
> - ARM9, FIXED_POINT, DOUBLE_PRECISION
> - f<s> = 48kHz
> - frame_size = 240 (p.ch.) (--> 5ms)
> - rate = 128 kbit/s (stereo)
> - vbr_rate = 0
> - prediction = 2
> - complexity = 10
>
> Why do we need additionally a GLOBAL_STACK_SIZE ?
> Could these allocations also be redirected to a common method, like
> celt_alloc() ?
>
> It is not really clear to me what is the idea behind the switches
> VAR_ARRAYS, USE_ALLOCA, GLOBAL_STACK_SIZE and how much RAM must be
> allocated (how/where?) for any (or at least for our) configuration ?
>
>
> thanks a lot for your answers,
> Marko.
>
>
>
> _______________________________________________
> celt-dev mailing list
> celt-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/celt-dev