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 _______________________________________________ FreeSWITCH-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
