Speex dev - Jan 2006 - Speex decode memory usage on an Arm processor (wideband)

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.

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?

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?


Thanks in advance.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20060102/1948c829/attachment.html

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

> > 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.
>
> 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 am using GCC version 3.4.4 for the Arm so I assume it supports the
C99 variable size arrays so what do I need to do to have it use the
real stack?   I assume even with this selected the code will still
malloc space for other items?

Does the amount of space needed vary based on the quality and
complexity used to compress the file or on the type of sound in the
file?  (so I know what combinations I need to test with)

Thanks
Tom