[asterisk-users] audio glitches in conference

[Marco Mouta]

Thanks to Tzafrir for the above mentiong documentation.

FYI

http://docs.tzafrir.org.il/dahdi-linux/README.html

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.

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.

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.

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.

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.

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:

strings dahdi.ko | grep source:

--
Marco Mouta


On Thu, Feb 25, 2010 at 8:15 AM, <marco.mouta at gmail.com> wrote:

> 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.
>
> What u report isn't new and is well known due to the fact u don't have a
> precise clock source for meetme..
>
> You need to have chan_dahdi dummie...
>
> Hope it helps.
> Marco Mouta
> Enviada do dispositivo sem fios BlackBerry®
>
> -----Original Message-----
> From: "Jeff Brower" <jbrower at signalogic.com>
> Date: Wed, 24 Feb 2010 18:25:07
> To: Jonathan Addleman<jono at redowl.ca>
> Cc: <asterisk-users at lists.digium.com>
> Subject: Re: [asterisk-users] audio glitches in conference
>
> Jonathan-
>
> > I'm having a problem with conferences both meetme and app_conference,
> > though I've done most of the testing with meetme.
> >
> > Essentially, I get little gaps in the audio - usually fewer than a dozen
> > or so samples, though it does vary. They seem to occur at random, but I
> > usually get one ever few seconds, on average. They also seem to delay
> > some buffer somewhere, so that if I start recording (via eagi) after the
> > conference has been established for half an hour or so, the stream
> > received by the eagi script delayed by about 10 seconds.
>
> How did you measure the gaps?  Using signal or speech analysis software to
> display the recording?  If you measure
> number of samples between the gaps, does it correspond to multiples of RTP
> packet payload length (for example, for 8
> kHz G711 multiples of 80 samples between gaps) ?
>
> -Jeff
>
> > First, the preliminaries: I'm on a debian lenny system, using the
> > 1:1.4.21.2~dfsg-3 asterisk package. This is a dedicated server - was
> > running xen, but I've shut down all the domU's to test if they were
> > interfering, so now there's no sharing going on.
> >
> > I've been testing with a simple eagi script to grab the audio from the
> > conference:
> > #!/bin/sh
> > cat /dev/fd/3 > /tmp/audio.raw
> >
> > I've been testing it using the following dialplan extensions:
> > [test]
> > exten => testeagi,1,Answer
> > exten => testeagi,n,Wait(3)
> > exten => testeagi,n,EAGI(testeagi.sh)
> >
> > exten => testmeet,1,Answer
> > exten => testmeet,n,MeetMe(testconf,1qd)
> >
> > exten => testsound,1,Answer
> > exten => testsound,n,Playback(testbeep-asterisk)
> >
> > (testbeep is just 30 seconds of sine wave)
> >
> > I've been trying things like this:
> >
> >
> >
> > originate Local/testsound at test extension testeagi at test
> >
> > The recorded audio plays back fine - no glitches.
> > (an example is at http://www.vecotourism.org/audio17.wav)
> >
> > originate Local/testeagi at test extension testmeet at test
> > originate Local/testsound at test extension testmeet at test
> >
> > This does have the glitches.
> > (an example is at http://www.vecotourism.org/audio18.wav)
> >
> > What could be causing this? And is there anything else I could be doing
> > to debug it? Thanks.
> >
> > --
> > Jon-o Addleman - http://www.redowl.ca
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> 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/20100225/d3a70068/attachment.htm