Speex dev - Apr 2006 - discontinous transmision causes discontinous sound

Hi, im working on a voIP application. In order to reduce the traffic, 
decided not to send "silence" blocks.

Firstly i used an algorithm based on the volume to determine what is 
silence, and now im using the return value of the preprocessor to 
determine that.

In both cases, after any not sent block, the next block of sound i send 
starts ok, then makes a little "pause" and then continues perfectly.

I think it is due to a loss context in the decoder (because in the 
encoder i process every frame).

I have tried to reset the decoder, decode with NULL bits or recreate the 
decoder, before decode the "sound" block, and no one of these
solutions
solved the problem or minimized it.

have any body experimented the same?

thank you.

On Wed, 2006-04-19 at 11:33 +0200, Jes?s Mori?n wrote:
> Hi, im working on a voIP application. In order to reduce the traffic, 
> decided not to send "silence" blocks.
> 
> Firstly i used an algorithm based on the volume to determine what is 
> silence, and now im using the return value of the preprocessor to 
> determine that.
Have you tried the builting DTX (SPEEX_ENABLE_VAD and SPEEX_ENABLE_DTX)?
It can also generate comfort noise at the other end.
 
> In both cases, after any not sent block, the next block of sound i send 
> starts ok, then makes a little "pause" and then continues
perfectly.
Not sure what you mean exactly, but it sounds a bit strange...
> I think it is due to a loss context in the decoder (because in the 
> encoder i process every frame).
Yes, the decoder becomes out of sync with the encoder, breaking the
pitch prediction in the same was as when there is packet loss (in this
case, it's really heavy loss).
> I have tried to reset the decoder, decode with NULL bits or recreate the 
> decoder, before decode the "sound" block, and no one of these
solutions
> solved the problem or minimized it.
What you need is to reset the encoder as well, so that the encoder and
decoder are in sync. But even then, you might get better results with
the builting DTX (except that the VAD is uses is not as good as the one
in the preprocessor).

	Jean-Marc

On 4/19/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>
wrote:
>
> On Wed, 2006-04-19 at 11:33 +0200, Jes?s Mori?n wrote:
> > Hi, im working on a voIP application. In order to reduce the traffic,
> > decided not to send "silence" blocks.
>
> > I have tried to reset the decoder, decode with NULL bits or recreate
the
> > decoder, before decode the "sound" block, and no one of
these solutions
> > solved the problem or minimized it.
>
> What you need is to reset the encoder as well, so that the encoder and
> decoder are in sync. But even then, you might get better results with
> the builting DTX (except that the VAD is uses is not as good as the one
> in the preprocessor).

Hmm, I think I am running into a similar problem in asterisk (see
http://bugs.digium.com/view.php?id=6993).

Basically on the transmitting side, what's happening in the ivr is:
create a new speex encoder, open and  transcode (from gsm to speex) a file
while sending it, close, destroy the encoder
create a new speex encoder, open and transcode a file (from ulaw to speex)
while sending it, close, destroy the encoder
repeat ad infinitum.

on the receiving side, the same decoder stays on all the time.

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

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.

The code's at http://www.asterisk.org/doxygen/codec__speex_8c.html


        Jean-Marc
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
>


--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20060419/8fcf4ee5/attachment.html