&gt;That's a totally different topic. I do intend to reduce the wb memory<br>&gt;usage, just like I did with the narrowband for 1.2beta1. Still, don't<br>&gt;know where you take this 160k Word32 number (640 kB). I don't think
<br>&gt;wideband requires anywhere near that amount of memory.<br><br>Sorry, it's 160kB. <br>What do you think?<br>and any suggestions for memory reduction?<br><br>Lianghu<br><br><br><div><span class="gmail_quote">On 11/16/06, 
<b class="gmail_sendername">Jean-Marc Valin</b> &lt;<a href="mailto:jean-marc.valin@usherbrooke.ca">jean-marc.valin@usherbrooke.ca</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt; Another issue is the memory allocations distributed so many places that<br>&gt; it's hard to provide a single memory initial function interface.<br>&gt;<br>&gt; In a VoIP case on ARM, the total memory size for speex codec should be
<br>&gt; known at the inital stage since&nbsp;&nbsp;all the&nbsp;&nbsp;memories are allocated<br>&gt; at the initial stage.<br><br>If you want everything in the same big block, all you need to do is<br>override the speex_alloc() function to give pointers to a big block
<br>you've previously allocated.<br><br>&gt; In my current implementation, all the memory allocations are collected<br>&gt; together to form one big structure like below,<br>&gt;<br>&gt; typedef struct&nbsp;&nbsp;{<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;EncState&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;enc_state;
<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;char&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stack[NB_ENC_STACK];<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;spx_word16_t winBuf[80];<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;spx_word16_t excBuf[612];<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;spx_word16_t swBuf[612];<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;spx_word16_t lagWindow[22];
<br><br>Yuk. That's so.... G.729 and ITU codecs :-) As much as you'd like<br>something like that, it would be a pain to maintain it. If you want<br>everything in one chunk, just go with the solution above.<br><br>&gt; The structure defined above is used to allocate all memories after call
<br>&gt; the&nbsp;&nbsp;initial function.<br>&gt;<br>&gt; The problem here is the size of the structure which is very large(160k<br>&gt; Word32) for wb which is unacceptable for ARM.<br><br>That's a totally different topic. I do intend to reduce the wb memory
<br>usage, just like I did with the narrowband for 1.2beta1. Still, don't<br>know where you take this 160k Word32 number (640 kB). I don't think<br>wideband requires anywhere near that amount of memory.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Jean-Marc
<br><br>&gt; Any suggestion?<br>&gt;<br>&gt; Regards,<br>&gt;<br>&gt; Lianghu<br>&gt;<br>&gt;<br>&gt; On 11/13/06, *Jean-Marc Valin* &lt;<a href="mailto:jean-marc.valin@usherbrooke.ca">jean-marc.valin@usherbrooke.ca</a><br>
&gt; &lt;mailto:<a href="mailto:jean-marc.valin@usherbrooke.ca">jean-marc.valin@usherbrooke.ca</a>&gt;&gt; wrote:<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Hi everyone,<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; As you may have guess, Speex 1.2 is slowly approaching, though there's
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; still a lot left to do so I can't say how long it'll take. I thought<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; this was the right time to ask if there's anything missing or that can<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; be improved to make 1.2 better. At this point, it can't be anything
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; major, but there are still some changes that are possible, e.g:<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; - Improving some component that doesn't behave very well.<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; - Improving a confusing API.<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; - Improving robustness of a component to a specific condition
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; - Adding a minor feature<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; ...<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; So what's your favourite &quot;I wish Speex could...&quot; or &quot;Speex sucks<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; because...&quot;? I won't promise I'll take everything into account, but I'll
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; do my best -- if not for 1.2, then maybe for 1.4. Oh, and no I will not<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; make Speex compatible with G.729 :-)<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jean-Marc<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; P.S. I finally got around to posting my trivial Speex client that shows
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; how to use Speex with the echo canceller, preprocessor and jitter<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; buffer. It's in svn at <a href="http://svn.xiph.org/trunk/speex/speexclient/">http://svn.xiph.org/trunk/speex/speexclient/</a><br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; _______________________________________________<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Speex-dev mailing list<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:Speex-dev@xiph.org">Speex-dev@xiph.org</a> &lt;mailto:<a href="mailto:Speex-dev@xiph.org">Speex-dev@xiph.org
</a>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://lists.xiph.org/mailman/listinfo/speex-dev">http://lists.xiph.org/mailman/listinfo/speex-dev</a><br>&gt;<br>&gt;<br></blockquote></div><br>