[Freeswitch-users] Call latency in conferences and echo test increases over time

[Robert L Mathews]

Anthony Minessale wrote:
> Like I said,
> The timer by default is designed to make sure that none of the audio is 
> lost for situations like FAX etc.

Right, that makes sense. I've updated the wiki entries I made to warn 
about this.


> We do not use sleep for the timers we have timer objects into the code 
> derived from a high priority thread sending conditional broadcasts to 
> the timer objects.

Sorry for not being clear. When I said it "sleeps", I just meant "the 
operating system isn't scheduling any FreeSWITCH threads to run for some 
period of time, for whatever reason".


> What kind of CPU are you using and what kind of hardware that you 
> suspect you are getting delayed cpu scheduling on a small number of calls?

Well, I'm using 2.4 GHz dual Xeons, but couldn't this situation happen 
on any hardware, if it also has non-FreeSWITCH processes consuming lots 
of CPU time?

That's because the timer needs to make sure that rtp_common_read() is 
called at least once every 20 ms. If it can't be called that often, for 
any reason, then FreeSWITCH will fall behind the RTP stream. At that 
point, audio latency will certainly increase unless some of the packets 
are discarded.

I could duplicate the latency on 1.0.4 by running many other 
non-FreeSWITCH processes on the same server, so that all the freeswitch 
threads get starved for CPU time. FreeSWITCH then can't read the RTP 
packets as fast as they come in, and since the 1.0.4 code didn't flush 
those extra packets in conferences, that caused noticeable latency.

Imposing heavy server load is obviously a silly thing to do, but 
something similar could happen on any server that fires up lots of 
non-FreeSWITCH, CPU-hungry processes. (In my case it was virus scanners.)

Not using a dedicated server is also silly if people care about call 
quality, but I was just initially using it for conferences, and I didn't 
care if some packets were dropped. But conference packet dropping didn't 
happen on 1.0.4. Instead, a noticeable lag developed, which I did care 
about.

Since 1.0.5 *does* work the way I expect in conferences and other 
bridged calls (discarding packets), I'm *definitely* not complaining -- 
please consider this a resolved issue! I agree that it makes sense to 
preserve all packets for some RTP streams such as faxes and DTMF 
recognition, and basing that decision on whether the call is bridged 
makes as much sense as anything else I can think of (although perhaps 
that flag isn't getting set properly for the third leg of 
eavesdrop-converted-to-three-way calls).

I've been impressed by the extremely high performance of FreeSWITCH. The 
conference latency I was hearing in 1.0.4 was caused by the fact that 
I'm stressing the server with separate, unrelated processes, which is a 
foolish thing to do if you care about audio quality. I was just hoping 
that FreeSWITCH could more gracefully deal with such foolishness in 
cases where people *don't* care about audio quality... and 1.0.5 does. 
That's perfect.

Thanks again!

-- 
Robert L Mathews, Tiger Technologies