<span class="Apple-style-span" style="font-family: serif; font-size: medium; "><div class="para"><p style="margin-top: 0.5em; margin-bottom: 0.5em; ">Thanks to Tzafrir for the above mentiong documentation.</p><p style="margin-top: 0.5em; margin-bottom: 0.5em; ">
FYI</p><p style="margin-top: 0.5em; margin-bottom: 0.5em; "><a href="http://docs.tzafrir.org.il/dahdi-linux/README.html">http://docs.tzafrir.org.il/dahdi-linux/README.html</a></p><p style="margin-top: 0.5em; margin-bottom: 0.5em; ">
A PBX system should generally have a single clock. If you are connected to a telephony provider via a digital interface (e.g: E1, T1) you should also typically use the provider's clock (as you get through the interface). Hence one important job of Asterisk is to provide timing to the PBX.</p>
</div><div class="para"><p style="margin-top: 0.5em; margin-bottom: 0.5em; ">DAHDI "ticks" once per millisecond (1000 times per second). On each tick every active DAHDI channel reads and 8 bytes of data. Asterisk also uses this for timing, through a DAHDI pseudo channel it opens.</p>
</div><div class="para"><p style="margin-top: 0.5em; margin-bottom: 0.5em; ">However, not all PBX systems are connected to a telephony provider via a T1 or similar connection. With an analog connection you are not synced to the other party. And some systems don't have DAHDI hardware at all. Even a digital card may be used for other uses or is simply not connected to a provider. DAHDI cards are also capable of providing timing from a clock on card. Cheap x100P clone cards are sometimes used for that purpose.</p>
</div><div class="para"><p style="margin-top: 0.5em; margin-bottom: 0.5em; ">If all the above fail, you can use the module dahdi_dummy to provide timing alone without needing any DAHDI hardware. It will work with most systems and kernels.</p>
</div><div class="para"><p style="margin-top: 0.5em; margin-bottom: 0.5em; ">You can check the DAHDI timing source with dahdi_test, which is a small utility that is included with DAHDI. It runs in cycles. In each such cycle it tries to read 8192 bytes, and sees how long it takes. If DAHDI is not loaded or you don't have the device files, it will fail immediately. If you lack a timing device it will hang forever in the first cycle. Otherwise it will just give you in each cycle the percent of how close it was. Also try running it with the option -v for a verbose output.</p>
</div><div class="para"><p style="margin-top: 0.5em; margin-bottom: 0.5em; ">To check the clock source that is built into dahdi_dummy, you can either look at title of its span in /proc/dahdi file for a "source:" in the description. Or even run:</p>
</div><div class="literalblock" style="margin-right: 100px; margin-top: 1.5em; margin-bottom: 1.5em; "><div class="content" style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; "><pre style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">
<tt style="color: navy; ">strings dahdi.ko | grep source:</tt></pre></div></div></span>--<br>Marco Mouta<br>
<br><br><div class="gmail_quote">On Thu, Feb 25, 2010 at 8:15 AM, <span dir="ltr"><<a href="mailto:marco.mouta@gmail.com">marco.mouta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It looks to me that u are having clock synchronism problems due to the fact you are using Virtual Machine so u don't have an ISDN card generating clock. Are u using what was called ztdummie as clock source? Can't precise the name of it in chan_dahdi but u have it.<br>
<br>
What u report isn't new and is well known due to the fact u don't have a precise clock source for meetme..<br>
<br>
You need to have chan_dahdi dummie...<br>
<br>
Hope it helps.<br>
Marco Mouta<br>
Enviada do dispositivo sem fios BlackBerry®<br>
<div><div></div><div class="h5"><br>
-----Original Message-----<br>
From: "Jeff Brower" <<a href="mailto:jbrower@signalogic.com">jbrower@signalogic.com</a>><br>
Date: Wed, 24 Feb 2010 18:25:07<br>
To: Jonathan Addleman<<a href="mailto:jono@redowl.ca">jono@redowl.ca</a>><br>
Cc: <<a href="mailto:asterisk-users@lists.digium.com">asterisk-users@lists.digium.com</a>><br>
Subject: Re: [asterisk-users] audio glitches in conference<br>
<br>
Jonathan-<br>
<br>
> I'm having a problem with conferences both meetme and app_conference,<br>
> though I've done most of the testing with meetme.<br>
><br>
> Essentially, I get little gaps in the audio - usually fewer than a dozen<br>
> or so samples, though it does vary. They seem to occur at random, but I<br>
> usually get one ever few seconds, on average. They also seem to delay<br>
> some buffer somewhere, so that if I start recording (via eagi) after the<br>
> conference has been established for half an hour or so, the stream<br>
> received by the eagi script delayed by about 10 seconds.<br>
<br>
How did you measure the gaps? Using signal or speech analysis software to display the recording? If you measure<br>
number of samples between the gaps, does it correspond to multiples of RTP packet payload length (for example, for 8<br>
kHz G711 multiples of 80 samples between gaps) ?<br>
<br>
-Jeff<br>
<br>
> First, the preliminaries: I'm on a debian lenny system, using the<br>
> 1:1.4.21.2~dfsg-3 asterisk package. This is a dedicated server - was<br>
> running xen, but I've shut down all the domU's to test if they were<br>
> interfering, so now there's no sharing going on.<br>
><br>
> I've been testing with a simple eagi script to grab the audio from the<br>
> conference:<br>
> #!/bin/sh<br>
> cat /dev/fd/3 > /tmp/audio.raw<br>
><br>
> I've been testing it using the following dialplan extensions:<br>
> [test]<br>
> exten => testeagi,1,Answer<br>
> exten => testeagi,n,Wait(3)<br>
> exten => testeagi,n,EAGI(testeagi.sh)<br>
><br>
> exten => testmeet,1,Answer<br>
> exten => testmeet,n,MeetMe(testconf,1qd)<br>
><br>
> exten => testsound,1,Answer<br>
> exten => testsound,n,Playback(testbeep-asterisk)<br>
><br>
> (testbeep is just 30 seconds of sine wave)<br>
><br>
> I've been trying things like this:<br>
><br>
><br>
><br>
> originate Local/testsound@test extension testeagi@test<br>
><br>
> The recorded audio plays back fine - no glitches.<br>
> (an example is at <a href="http://www.vecotourism.org/audio17.wav" target="_blank">http://www.vecotourism.org/audio17.wav</a>)<br>
><br>
> originate Local/testeagi@test extension testmeet@test<br>
> originate Local/testsound@test extension testmeet@test<br>
><br>
> This does have the glitches.<br>
> (an example is at <a href="http://www.vecotourism.org/audio18.wav" target="_blank">http://www.vecotourism.org/audio18.wav</a>)<br>
><br>
> What could be causing this? And is there anything else I could be doing<br>
> to debug it? Thanks.<br>
><br>
> --<br>
> Jon-o Addleman - <a href="http://www.redowl.ca" target="_blank">http://www.redowl.ca</a><br>
<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br>