Robert McGilvray wrote: <snip>
Before I rip apart the environment and rebuild on physical I’d like to try and confirm that hypothesis. In the past this was a simple matter of running dahdi_test which would report the accuracy. I’m not sure how to interpret the results of “timing test” in the Asterisk CLI. If I increase the number of ticks per second the results are erratic while under load. I’m using the timerfd module in Asterisk with a 1000HZ tick kernel and high res timers enabled. I’ve tried both hpet and tsc as system clock sources, both exhibit the same breaks in audio. It sounds like someone presses the mute button in the middle of a sentence.
"timing test" does similar, it just doesn't do the automatic calculation. Confbridge normally operates at a mixing interval of 20ms, which is 50 ticks per second. That would be what you would want to test. If you don't get 50 per second then that means ConfBridge will not provide a steady source of media to each participant and it will be up to each remote jitterbuffer to handle the delayed traffic. Enough of it and stuff goes wonky. You could also see this on a packet capture. That would determine if it's timing related or not.
-- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
