[Speex-dev] Speex decode memory usage on an Arm processor (wideband)

[Jean-Marc Valin]

On Mon, 2006-01-02 at 22:37 -0500, tom abcd wrote:
> I am hoping to use Speex for a embedded project using Philips Arm
> processor (50 mips) 512kb flash 32kb ram.  I found in the manual that
> decode takes about 0.5 mips so I should have enough processing power
> and I compiled the lib and it seems to take less then 64K so the only
> issue is memory usage.  I have been testing the speex decode on
> windows looking at the stack usage and how much is malloc.  There
> appear to be three defines that control much of the memory usage:
> MAX_CHARS_PER_FRAME , SB_DEC_STACK and NB_DEC_STACK.  

MAX_CHARS_PER_FRAME is different from the others. It's a sort of
shortcut to remove the need to resize the bit-packer buffer. If you know
what you're going to decode, supply your own buffer or can live with
realloc() calls, then you can ignore/reduce that one.

> I have tested lowering these values and then running the speexdec
> program and looking for errors.  By trial and error it appears that I
> can lower  MAX_CHARS_PER_FRAME  = 750,   SB_DEC_STACK =
> 750*sizeof(spx_sig_t)  and NB_DEC_STACK = 250*sizeof(spx_sig_t) 
> and not get any memory errors but have no idea if these are safe
> values or not.  I could not tell how much stack spaced was used but
> would guess 4 kb would be enough.   After making these changes it
> appears to Alloc less the 16kb. 
>
> So any pointers on what is the min memory needed for wideband decode
> on a ARM process?  Can it all be done in 20 kb or less?  Any
> suggestions on what choices cause more memory usage? 


Best is to set these values by trial and error. I've used values I'm
confident with for fixed-point and float at the same time. Actually,
even better is to use a compiler that supports C99 variable-size arrays
(gcc does) or at least alloca. That way, the real stack is used instead
of that artificial stack, reducing overall memory.

> I will control how the files are compressed and I am not using the Ogg
> file structure but just the simple count data approach given in the
> manual example.  I also notice that the Speexdec win32 example skips
> some of the first bytes from the decode process.  It seems to be using
> the LOOK_AHEAD amount but I can not find anything in the manual about
> this.   So is some of the first data out of the decode not used?

The encoder has a look-ahead for LPC analysis, so it introduces a delay.
That means the first few samples are zero (or close). That's why the
decoder skips those samples to have "gapless" playback. If you don't
skip them, most likely nobody will notice anyway (unless concatenating
two output files).

	Jean-Marc