[Speex-dev] Quick survey for Speex 1.2

[lianghu xu]

>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.

Sorry, it's 160kB.
What do you think?
and any suggestions for memory reduction?

Lianghu


On 11/16/06, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote:
>
> > 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20061116/5db8ec59/attachment.htm