<br><br><div><span class="gmail_quote">On 4/19/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;">
On Wed, 2006-04-19 at 11:33 +0200, Jesús Morión wrote:<br>> Hi, im working on a voIP application. In order to reduce the traffic,<br>> decided not to send "silence" blocks.<br><br>> I have tried to reset the decoder, decode with NULL bits or recreate the
<br>> decoder, before decode the "sound" block, and no one of these solutions<br>> solved the problem or minimized it.<br><br>What you need is to reset the encoder as well, so that the encoder and<br>decoder are in sync. But even then, you might get better results with
<br>the builting DTX (except that the VAD is uses is not as good as the one<br>in the preprocessor).</blockquote><div><br>Hmm, I think I am running into a similar problem in asterisk (see <a href="http://bugs.digium.com/view.php?id=6993">
http://bugs.digium.com/view.php?id=6993</a>).<br><br>Basically on the transmitting side, what's happening in the ivr is:<br>create a new speex encoder, open and transcode (from gsm to speex) a file while sending it, close, destroy the encoder
<br>create a new speex encoder, open and transcode a file (from ulaw to speex) while sending it, close, destroy the encoder<br>repeat ad infinitum.<br><br>on the receiving side, the same decoder stays on all the time.<br>
<br>The symptoms are varied. One symptom is short audio sequences get lost on the receiving side. Another is my packet stream jitters like mad (see packet trace in above bug). I was thinking of addressing some of the latter (theory being that it took too long to create a new encoder) problem with pre-allocating encoders (as calling malloc/calloc in a rt thread is a bad idea), but it would be better to always leave one encoder and decoder running, but definately having the encoder always tell the decoder that it's stream has changed regardless...
<br><br>so... what do you mean by "reset the encoder"? Am I not closing the stream properly and need to send a final frame of some sort on the way out? (see speextolin destroy and the framein/frameout.... code). I've tried it with various combinations of dtx/vad/quality etc.
<br></div><br>The code's at <a href="http://www.asterisk.org/doxygen/codec__speex_8c.html">http://www.asterisk.org/doxygen/codec__speex_8c.html</a><br><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jean-Marc<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><br clear="all"><br>-- <br>Mike Taht<br>PostCards From the Bleeding Edge<br><a href="http://the-edge.blogspot.com">http://the-edge.blogspot.com</a>