|
Hi Tony Thanks for the reply and for
posting the code. I added the code and recompiled Asterisk, but unfortunately
it did not resolve the issue. It basically trapped all of the incoming audio
and wrote to the error log instead of outputting it. So basically it never
seemed to go to the careful_write statement. To answer your questions:
Firstly, I am using kernel 2.6, but am not using Ztdummy. I am using a digium
card for timing. I have run a test on it, and it seems to be working properly. I am using a client built
using IaxClient, and am now looking at the possibility that the delay might be
a client issue instead of a server issue. What is the best tool to use to run
tests on my server and clients to narrow down the source of the delay? Many thanks Steven > Date: Wed, 12 Oct 2005
10:41:33 +0000 (UTC) > From:
[EMAIL PROTECTED] (Tony Mountifield) > Subject:
[Asterisk-Users] Re: delays with IAX2 and Meetme > To: > Message-ID:
<[EMAIL PROTECTED]> > > In article
<[EMAIL PROTECTED]>, > Steven Langley < >> >> I am using IAX2
softphones dialing into meetme conferences. I also have >> jitterbuffer=yes,
with typical jitterbuffer settings. The problem I am >> having is that as
soon as there is a delay from a participant, then the >> delay continues
until the participant hangs up and dials in again. When >> dialing in again
the delay seems to go. >> >> It seems to me as
though as soon as the server registers a delay from a >> participant, then
it causes delay on all further packets from that >> participant. >> >> Does anyone have
any ideas what the problem could be? > > Yes, there are a few
possibilities. Firstly, are you using ztdummy for > timing? Which kernel
version? If 2.6, have you ensured that USE_RTC is > correctly defined in
ztdummy.c? > > Look in bugs.digium.com
at bug IDs 3599 and 4252 - they might be relevant. > > Yesterday I found
another mechanism which could give rise to both a delay > and broken audio - I
found it with OH323 channels, but it might possibly > arise on other channel
types too. It concerns a backlog building up in > the channel driver and
never being drained by meetme because of blocking > in the pseudo-device
when trying to write the contents of a large frame. > > In app_meetme.c, try
replacing this: > > careful_write(fd,
f->data, f->datalen); > > with this: > > if (f->datalen <=
CONF_SIZE) { >
careful_write(fd, f->data, f->datalen); > } else { > ast_log(LOG_WARNING,
"Discarding large frame (%d bytes) from channel %s\n", f->datalen,
chan->name); > } > > and see if it helps. > > I haven't yet submitted
the above change to mantis. > > Cheers > Tony > -- > Tony Mountifield > Work:
[EMAIL PROTECTED] - http://www.softins.co.uk > Play:
[EMAIL PROTECTED] - http://tony.mountifield.org |
_______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com --
Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
