[Asterisk-Dev] Re: How to measure delay in meetme?

[Tony Mountifield]

In article <Pine.LNX.4.61.0508291047590.6780 at fs.sedwards.com>,
Steve Edwards <asterisk.org at sedwards.com> wrote:
> On Mon, 29 Aug 2005, Tony Mountifield wrote:
> 
> > I've never found problems with delay when only Zap channels are involved;
> 
> Personally, I don't think anybody would notice in a real conversation, but 
> you can notice it if you have a separate phone to each ear or if you 
> listen on one handset and tap the table with the other.

As you say below, the same will be true in any digital connection.

> > So Steve, your MeetMe conferences *only* involve Zap channels on your
> > T1 connection? And it is in these that the boss complains of delay?
> > With no VoIP channels involved?
> 
> Zap only.
> 
> Looking at the "show channel" for all involved, the Zap/N channels have 
> Native, Write, Read of 68, 64, 64 and the Zap/pseudo channel shows 68, 4, 
> 4. Would there be anything gained by trying to get everybody to use the 
> same codec?

Yes, all codecs involve a trascoding operation if talking to a different
codec, and this takes time, depending on the speed of the CPU. I'm not
sure what happens in MeetMe if Zap channels with transcoding are involved. 

In fact, thinking about it more, on T1 channels, I don't believe there
is any means to negotiate codec - you just get uLaw audio from the telco
or PBX and that's standard.

> Are there any gains to be made fiddling with echo, buffer, or jitter 
> parameters?

Echo cancellation will involve some kind of delay, and you should turn
it off if possible, in /etc/asterisk/zapata.conf:

echocancel=no

If you had it turned on before, you may find turning it off reduces the
delay. I have 8 systems each running 4xT1 with echocancel=no, and have
had no complaints of echo since they were installed nearly a year ago.

> I'd really like to be able to measure the delay. This would allow me to 
> make a rational argument like "cell phones have a delay of x ms and 
> nobody notices" or "research shows the limit of human perception is y ms."
> 
> This would also allow me to tell if any of the changes I make actually do 
> anything :)

Well one way would be to connect a microphone to a PC and position it so
it can hear both the input and output audio. Record using a program such
as GoldWave that can show you the waveform calibrated against time, and
use a sudden short sound that you can easily identify in the display.

Hope this helps

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org