[asterisk-dev] MeetMe huge delays

[Paulo Garcia]

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 <tony at softins.clara.co.uk> wrote:
>
> Hi Paulo,
>
> In article <b850d66b0709191000v758fa7d1n8e4400022b2b7ae7 at mail.gmail.com>,
> Paulo Garcia <paulo.astdev at gmail.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=0003599seems
> > 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: tony at softins.co.uk - http://www.softins.co.uk
> Play: tony at mountifield.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070920/d53577e7/attachment.htm