|
List Info
Thread: MeetMe huge delays
|
|
| MeetMe huge delays |
|
2007-09-19 12:00:37 |
|
Hi,
I'm having some strange behavior using our channel driver with MeetMe application. I'm testing using Asterisk 1.2.24 and zaptel/ztdummy 1.2.20.1.
After some research, I've find an old issue in bugtrack
http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0003599 that discribes exactly the problem I'm having.
1> Using the "i" parameter in MeetMe, I have a huge delay between two participants. The delay is exacly the time of the enter message in the conference with the name of the participant.
2> Removing the "i", using only cM, for example I still have a little delay (about 500ms)
3> Using the "q" parameter, I have no delays at all.
The
http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0003599 seems to be closed and fixed but I'm wonder to know if the problem still exists using non-zaptel channels or if I missed something to handle this in my channel driver.
Any ideas?
Thanks in advance!
--
--------------
Paulo Garcia
Pika Technologies Inc
|
| Re: MeetMe huge delays |
 
United Kingdom |
2007-09-20 03:48:16 |
Hi Paulo,
In article
<b850d66b0709191000v758fa7d1n8e4400022b2b7ae7 mail.gmail.com>,
Paulo Garcia <paulo.astdevgmail.com> wrote:
> I'm having some strange behavior using our channel
driver with MeetMe
> application. I'm testing using Asterisk 1.2.24 and
zaptel/ztdummy 1.2.20.1.
>
> After some research, I've find an old issue in
bugtrack
> http://bugs.digium.com/bug_view_advanced_page.ph
p?bug_id=0003599 that
> discribes exactly the problem I'm having.
That bug report is one of mine.
> 1> Using the "i" parameter in MeetMe, I
have a huge delay between two
> participants. The delay is exacly the time of the enter
message in the
> conference with the name of the participant.
> 2> Removing the "i", using only cM, for
example I still have a little delay
> (about 500ms)
> 3> Using the "q" parameter, I have no
delays at all.
>
> The http://bugs.digium.com/bug_view_advanced_page.ph
p?bug_id=0003599 seems
> to be closed and fixed but I'm wonder to know if the
problem still exists
> using non-zaptel channels or if I missed something to
handle this in my
> channel driver.
Although the bug was closed and "fixed", I was
never satisfied that it was
fixed correctly. The powers that be never adopted the
asynchronous thread
approach that I submitted as my fix. Life was too short to
keep arguing
about it.
I build a lot of MeetMe systems and incorporate my own patch
into them
all. I expect I will still have to do so when I move to 1.4,
but I haven't
tested 1.4 yet. It certainly doesn't appear to have
asynchronous play.
Please try applying the last patch listed under that bug
(head-v4). You
may need to apply quite a bit of it by hand, as I expect the
patch doesn't
apply cleanly any more.
If it fixes your problem (as I expect it will), I can only
suggest you do
as I do, and keep your own working version of app_meetme.c.
Something else that I found helped enormously was another
patch that was
too late to be included in 1.2 (pity).
You can find it at bug 5374: http://bugs.d
igium.com/view.php?id=5374
There are various patches there, but the one I find best,
and include in
all 1.2 systems that I build, is called
2005-10-04-3-asynchronous.patch
It is the channel.c mods that are important. The changes to
app_milliwatt,
app_sms and app_chanspy will only matter if you use those
modules.
> Any ideas?
>
> Thanks in advance!
Hope this helps. Please let the list know how you get on
with the patches.
Cheers
Tony
--
Tony Mountifield
Work: tonysoftins.co.uk - http://www.softins.co.uk
Play: tonymountifield.org - http://tony.mountifield.o
rg
_______________________________________________
Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
|
|
| Re: MeetMe huge delays |
|
2007-09-20 09:20:36 |
|
Hi Tony,
first, thank you for your well-done explanation for me.
I checked my channel driver code and it is using an approach to get the samples from our card using our own method and write to a pipe to wakeup the read call back. I saw that during the announcing message in conference, the Asterisk doesn't process any queued VOICE_FRAME sent by my read callback.
After changing my code to avoid using read callback (which isnt necessary) the delay doesn't occurs anymore but I had warning messages that my voice frames are being dropped because the thread is to big, which proves that Asterisk stops to read the frames during those playback messages.
I'll try your patch today to see if those behaviors disappear and I'll post the results here.
Thanks
On 9/20/07, Tony Mountifield
< tonysoftins.clara.co.uk">tonysoftins.clara.co.uk> wrote:
Hi Paulo,
In article < b850d66b0709191000v758fa7d1n8e4400022b2b7ae7mail.gmail.com">b850d66b0709191000v758fa7d1n8e4400022b2b7ae7mail.gmail.com>,
Paulo Garcia < paulo.astdevgmail.com">
paulo.astdevgmail.com> wrote:
>; I'm having some strange behavior using our channel driver with MeetMe
>; application. I'm testing using Asterisk 1.2.24 and zaptel/ztdummy
1.2.20.1.
>
>; After some research, I've find an old issue in bugtrack
> http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0003599
that
> discribes exactly the problem I'm having.
That bug report is one of mine.
>; 1> Using the "i" parameter in MeetMe, I have a huge delay between two
> participants. The delay is exacly the time of the enter message in the
> conference with the name of the participant.
> 2> Removing the "i", using only cM, for example I still have a little delay
> (about 500ms)
>; 3> Using the "q" parameter, I have no delays at all.
>;
> The http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0003599 seems
> to be closed and fixed but I'm wonder to know if the problem still exists
> using non-zaptel channels or if I missed something to handle this in my
> channel driver.
Although the bug was closed and "fixed", I was never satisfied that it was
fixed correctly. The powers that be never adopted the asynchronous thread
approach that I submitted as my fix. Life was too short to keep arguing
about it.
I build a lot of MeetMe systems and incorporate my own patch into them
all. I expect I will still have to do so when I move to
1.4, but I haven't
tested 1.4 yet. It certainly doesn't appear to have asynchronous play.
Please try applying the last patch listed under that bug (head-v4). You
may need to apply quite a bit of it by hand, as I expect the patch doesn't
apply cleanly any more.
If it fixes your problem (as I expect it will), I can only suggest you do
as I do, and keep your own working version of app_meetme.c.
Something else that I found helped enormously was another patch that was
too late to be included in 1.2 (pity).
You can find it at bug 5374: http://bugs.digium.com/view.php?id=5374
There are various patches there, but the one I find best, and include in
all 1.2 systems that I build, is called 2005-10-04-3-asynchronous.patch
It is the channel.c mods that are important. The changes to app_milliwatt,
app_sms and app_chanspy will only matter if you use those modules.
> Any ideas?
>;
> Thanks in advance!
Hope this helps. Please let the list know how you get on with the patches.
Cheers
Tony
--
Tony Mountifield
Work: tonysoftins.co.uk">
tonysoftins.co.uk - http://www.softins.co.uk
Play: tonymountifield.org">tonymountifield.org - http://tony.mountifield.org
_______________________________________________
Sign up now for AstriCon 2007! ; September 25-28th. http://www.astricon.net/
--Bandwidth and Colocation Provided by
http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
--
--------------
Paulo Garcia
Pika Technologies Inc
|
[1-3]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|