[Asterisk-Dev] IAX timing of VOICE frames

[Derek Smithies]

Hi,
 you can send a packet dump to me if you like.

tcpdump  -s 2000 -w log_for_derek 

  
and I will have a look through for anything odd.

=============================================================

There is always an issue in the rate at which sound frames are generated. 
Like, if you use an audio card as the source of timing for the frames,
they will have a different idea of how long 20 msecs is.


Can you get log file output from the asterisk box - anything of note?

Derek.



On Tue, 13 Sep 2005, Lee Howard wrote:

> Derek Smithies wrote:
> 
> >Hi,
> > I found in the C++ version of IAX2 that I wrote for the OPAL library at 
> >www.voxgratia.org that
> >
> >the timestamps had to represent the time at which the frame was 
> >generated, not when it was actually sent.
> >  
> >
> 
> Thanks.  This helped quite a bit.  Apparently I was occassionally 
> getting a short read from the original audio source, which threw off the 
> "voice timestamp prediction" facility in the client.  (Some frames would 
> actually end up with less than 160 samples, and that caused a shortened 
> adjustment in the timestamp prediction.)  I fixed that by ensuring that 
> all voice frames contained a full 160 samples (with the exception of 
> possibly the last frame in a call).
> 
> However, I've also noticed that the time when the frame actually gets 
> sent still influences things.  If I generate and send the frames exactly 
> 20000 u-sec apart I find frequent short (very short) audio cut-outs.  (I 
> presume this is because of a "audio buffer underrun" of sorts either on 
> the Asterisk server or on the other endpoint.)  If I generate and send 
> the frames 19000 u-sec apart then I get "pops" in the audio.  (I presume 
> this is because the server or the other endpoint has to "merge" a bit of 
> audio from one frame with another because of the apparent clock skew, an 
> "audio buffer overrun" - 20ms frames consistently arriving more quickly 
> than every 20ms.)  The happy median seems to be around 19930 u-sec, but 
> I suspect that would change if network conditions changed.
> 
> >Have you looked at the packet dump with ethereal? what do you observe - 
> >are the packets coming too quickly, or are there some missing ??
> >  
> >
> 
> I have not looked at a packet dump with ethereal.  I'm not sure that I 
> would know what to look for, anyway.
> 
> >What jitter buffer are you using ?
> >Despite any urban myths you might have heard, a quality jitter buffer is
> >essential to copy with variability in the rate at which packets are
> >transmitted, and variability in network performance.
> >  
> >
> 
> I believe this entirely.
> 
> I'm using CVS v1_0, and I don't really understand what jitter buffer 
> options there are.  I've tried with jitterbuffer=yes and with =no, in 
> iax.conf, and I've tried enabling and disabling the buffer in the IAX 
> client.
> 
> Currently I'm testing with a simple IAX client program written from a 
> slightly modified version of libiax2 which is basically taking quickly 
> repeating and predictable audio samples from a source and sending them 
> through Asterisk to a SIP phone (Grandstream BT101) that I have.  I 
> don't know if the appropriate jitter buffer to question here is that on 
> the SIP phone or elsewhere.
> 
> Thanks,
> 
> Lee.
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

-- 
Derek Smithies Ph.D.                 Any fool can write code that 
IndraNet Technologies Ltd.                a computer can understand.        
Email: derek at indranet.co.nz         Good programmers write code 
ph +64 3 365 6485                          that humans can understand.
Web: http://www.indranet-technologies.com/            Martin Fowler