<div dir="ltr"><div>>Information on timing sources can be found here:</div><div><br></div><div>><a href="https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces">https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces</a></div><div><br></div><div>>As noted on that page, ConfBridge can use any timing interface Asterisk</div><div>>provides, and is not limited to the DAHDI timing interface. Generally,</div><div>>timerfd is a good timing interface.</div><div><br></div><div>>That aside, I would try to rule out external issues with the garbled audio</div><div>>before changing the timing source. Things like:</div><div>> - Analysis of the RTP traffic (along with potential jitter)</div><div>> - CPU utilization with an active conference (95% idle doesn't mean that</div><div>>some core isn't pegged)</div><div>> - Any potential transcoding issues or codec issues</div><div><br></div><div>>Matt</div><div><br></div><div>Hi Matt - thanks.</div><div><br></div><div>Looks like I am ONLY loading:</div><div>res_timing_pthread</div><div>res_timing_dahdi</div><div><br></div><div>But I dont think the res_timing(x) is working on CentOS 5.   res_timing_timerfd does not </div><div>even seem to be compiled on this box. </div><div><br></div><div>How do I tell for sure what its using and if its good. All I saw in the asterisk log was the </div><div>two res_timing_pthread and res_timing_dadhi being loaded.</div><div><br></div><div><br></div><div>Everything else is fine actually. It worked with the card, and withthout the card just sending audio to </div><div>one endpoint has audio issues in a conference. The machine is doing nothign else at that time.</div><div><br></div><div>Thanks,</div><div><br></div><div>Jerry</div><div class="gmail_extra"><br></div></div>