[asterisk-users] Asterisk 11.24.1 garbled audio

[Olivier]

Hi,

How can I double check which timer is currently is use in a running system ?
core show settings doesn't tell anything, if I'm not mistaken.


Regards

2016-11-11 21:02 GMT+01:00 Matthew Jordan <mjordan at digium.com>:

>
>
> On Fri, Nov 11, 2016 at 10:46 AM, Jerry Geis <jerry.geis at gmail.com> wrote:
>
>> >Information on timing sources can be found here:
>>
>> >https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces
>>
>> >As noted on that page, ConfBridge can use any timing interface Asterisk
>> >provides, and is not limited to the DAHDI timing interface. Generally,
>> >timerfd is a good timing interface.
>>
>> >That aside, I would try to rule out external issues with the garbled
>> audio
>> >before changing the timing source. Things like:
>> > - Analysis of the RTP traffic (along with potential jitter)
>> > - CPU utilization with an active conference (95% idle doesn't mean that
>> >some core isn't pegged)
>> > - Any potential transcoding issues or codec issues
>>
>> >Matt
>>
>> Hi Matt - thanks.
>>
>> Looks like I am ONLY loading:
>> res_timing_pthread
>> res_timing_dahdi
>>
>> But I dont think the res_timing(x) is working on CentOS 5.
>> res_timing_timerfd does not
>> even seem to be compiled on this box.
>>
>> How do I tell for sure what its using and if its good. All I saw in the
>> asterisk log was the
>> two res_timing_pthread and res_timing_dadhi being loaded.
>>
>>
>> Everything else is fine actually. It worked with the card, and withthout
>> the card just sending audio to
>> one endpoint has audio issues in a conference. The machine is doing
>> nothign else at that time.
>>
>>
>>
> You're probably running a version of the Linux kernel that doesn't support
> timerfd, hence why it isn't available.
>
> res_timing_pthread is ... not very good. It exists as an absolute, last
> ditch fall-back for Asterisk to provide a source of timing when none
> exists. As such, and assuming you have ruled out all other sources of the
> garbled audio, then I'm really not surprised that it isn't very effective.
>
> Your best bet would be to:
>  - Provide a hardware timing source that res_timing_dahdi can use. IIRC,
> this should work even without a specific card, but does require the dahdi
> kernel module to be installed and available. (I could be wrong on the need
> for a physical card however, so your mileage may vary.)
>  - Upgrade to a version of the kernel that res_timing_timerfd supports.
> That should be Linux 2.6.26 and glibc 2.8 or later.
>
> Personally, if I were in your shoes, I'd go with the latter. CentOS 6
> should be good out of the box, and CentOS 5 is pretty long in the tooth.
>
> Matt
> --
> Matthew Jordan
> Digium, Inc. | CTO
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at: https://community.asterisk.
> org/
>
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20161115/08812fc3/attachment.html>