[Speex-dev] Quick survey for Speex 1.2

[Jean-Marc Valin]

> Another issue is the memory allocations distributed so many places that
> it's hard to provide a single memory initial function interface.
> 
> In a VoIP case on ARM, the total memory size for speex codec should be
> known at the inital stage since  all the  memories are allocated
> at the initial stage.

If you want everything in the same big block, all you need to do is
override the speex_alloc() function to give pointers to a big block
you've previously allocated.

> In my current implementation, all the memory allocations are collected
> together to form one big structure like below,
> 
> typedef struct  {
> 
>    EncState                    enc_state;
> 
>    char                           stack[NB_ENC_STACK];
> 
>    spx_word16_t winBuf[80];
> 
>    spx_word16_t excBuf[612];
> 
>    spx_word16_t swBuf[612];
> 
>    spx_word16_t lagWindow[22];

Yuk. That's so.... G.729 and ITU codecs :-) As much as you'd like
something like that, it would be a pain to maintain it. If you want
everything in one chunk, just go with the solution above.

> The structure defined above is used to allocate all memories after call
> the  initial function.
> 
> The problem here is the size of the structure which is very large(160k
> Word32) for wb which is unacceptable for ARM.

That's a totally different topic. I do intend to reduce the wb memory
usage, just like I did with the narrowband for 1.2beta1. Still, don't
know where you take this 160k Word32 number (640 kB). I don't think
wideband requires anywhere near that amount of memory.

	Jean-Marc

> Any suggestion?
> 
> Regards,
> 
> Lianghu
> 
> 
> On 11/13/06, *Jean-Marc Valin* <jean-marc.valin at usherbrooke.ca
> <mailto:jean-marc.valin at usherbrooke.ca>> wrote:
> 
>     Hi everyone,
> 
>     As you may have guess, Speex 1.2 is slowly approaching, though there's
>     still a lot left to do so I can't say how long it'll take. I thought
>     this was the right time to ask if there's anything missing or that can
>     be improved to make 1.2 better. At this point, it can't be anything
>     major, but there are still some changes that are possible, e.g:
> 
>     - Improving some component that doesn't behave very well.
>     - Improving a confusing API.
>     - Improving robustness of a component to a specific condition
>     - Adding a minor feature
>     ...
> 
>     So what's your favourite "I wish Speex could..." or "Speex sucks
>     because..."? I won't promise I'll take everything into account, but I'll
>     do my best -- if not for 1.2, then maybe for 1.4. Oh, and no I will not
>     make Speex compatible with G.729 :-)
> 
>             Jean-Marc
> 
>     P.S. I finally got around to posting my trivial Speex client that shows
>     how to use Speex with the echo canceller, preprocessor and jitter
>     buffer. It's in svn at http://svn.xiph.org/trunk/speex/speexclient/
>     _______________________________________________
>     Speex-dev mailing list
>     Speex-dev at xiph.org <mailto:Speex-dev at xiph.org>
>     http://lists.xiph.org/mailman/listinfo/speex-dev
> 
>