Hi All,<br><br>Another issue is the memory allocations distributed so many places that it's hard to provide a single memory initial function interface.<br><br>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
<br>at the initial stage.<br> <br>In my current implementation, all the memory allocations are collected together to form one big structure like below,<br><br><div class="Section1">
<p class="MsoNormal"><font face="Arial" size="2"><span style="">typedef struct {</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style=""> EncState enc_state;</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style=""> char stack[NB_ENC_STACK];</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style=""> spx_word16_t winBuf[80];</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style=""> spx_word16_t excBuf[612];</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style=""> spx_word16_t swBuf[612];</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style=""> spx_word16_t lagWindow[22];</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style=""> ............................................ </span></font><br></p><p class="MsoNormal"><font face="Arial" size="2"><span style=""> int pitch[16];
</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style=""> VBRState vbr;</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span style="">} speex_encoder_memory;</span></font></p>
</div>The structure defined above is used to allocate all memories after call the initial function.<br><br>The problem here is the size of the structure which is very large(160k Word32) for wb which is unacceptable for ARM.
<br><br>Any suggestion?<br><br>Regards,<br><br>Lianghu<br><br><br><div><span class="gmail_quote">On 11/13/06, <b class="gmail_sendername">Jean-Marc Valin</b> <<a href="mailto:jean-marc.valin@usherbrooke.ca">jean-marc.valin@usherbrooke.ca
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi everyone,<br><br>As you may have guess, Speex 1.2 is slowly approaching, though there's
<br>still a lot left to do so I can't say how long it'll take. I thought<br>this was the right time to ask if there's anything missing or that can<br>be improved to make 1.2 better. At this point, it can't be anything<br>
major, but there are still some changes that are possible, e.g:<br><br>- Improving some component that doesn't behave very well.<br>- Improving a confusing API.<br>- Improving robustness of a component to a specific condition
<br>- Adding a minor feature<br>...<br><br>So what's your favourite "I wish Speex could..." or "Speex sucks<br>because..."? I won't promise I'll take everything into account, but I'll<br>do my best -- if not for
1.2, then maybe for 1.4. Oh, and no I will not<br>make Speex compatible with G.729 :-)<br><br> Jean-Marc<br><br>P.S. I finally got around to posting my trivial Speex client that shows<br>how to use Speex with the echo canceller, preprocessor and jitter
<br>buffer. It's in svn at <a href="http://svn.xiph.org/trunk/speex/speexclient/">http://svn.xiph.org/trunk/speex/speexclient/</a><br>_______________________________________________<br>Speex-dev mailing list<br><a href="mailto:Speex-dev@xiph.org">
Speex-dev@xiph.org</a><br><a href="http://lists.xiph.org/mailman/listinfo/speex-dev">http://lists.xiph.org/mailman/listinfo/speex-dev</a><br></blockquote></div><br>