Hi Tony,<br><br>first, thank you for your well-done explanation for me.<br><br>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.
<br><br>After changing my code to avoid using read callback (which isnt necessary) the delay doesn't occurs anymore <span style="font-weight: bold;">but</span> 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.
<br><br>I'll try your patch today to see if those behaviors disappear and I'll post the results here.<br><br>Thanks<br><br><div><span class="gmail_quote">On 9/20/07, <b class="gmail_sendername">Tony Mountifield</b>
<<a href="mailto:tony@softins.clara.co.uk">tony@softins.clara.co.uk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Paulo,<br><br>In article <<a href="mailto:b850d66b0709191000v758fa7d1n8e4400022b2b7ae7@mail.gmail.com">b850d66b0709191000v758fa7d1n8e4400022b2b7ae7@mail.gmail.com</a>>,<br>Paulo Garcia <<a href="mailto:paulo.astdev@gmail.com">
paulo.astdev@gmail.com</a>> wrote:<br>> I'm having some strange behavior using our channel driver with MeetMe<br>> application. I'm testing using Asterisk 1.2.24 and zaptel/ztdummy <a href="http://1.2.20.1">
1.2.20.1</a>.<br>><br>> After some research, I've find an old issue in bugtrack<br>> <a href="http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0003599">http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0003599
</a> that<br>> discribes exactly the problem I'm having.<br><br>That bug report is one of mine.<br><br>> 1> Using the "i" parameter in MeetMe, I have a huge delay between two<br>> participants. The delay is exacly the time of the enter message in the
<br>> conference with the name of the participant.<br>> 2> Removing the "i", using only cM, for example I still have a little delay<br>> (about 500ms)<br>> 3> Using the "q" parameter, I have no delays at all.
<br>><br>> The <a href="http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0003599">http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0003599</a> seems<br>> to be closed and fixed but I'm wonder to know if the problem still exists
<br>> using non-zaptel channels or if I missed something to handle this in my<br>> channel driver.<br><br>Although the bug was closed and "fixed", I was never satisfied that it was<br>fixed correctly. The powers that be never adopted the asynchronous thread
<br>approach that I submitted as my fix. Life was too short to keep arguing<br>about it.<br><br>I build a lot of MeetMe systems and incorporate my own patch into them<br>all. I expect I will still have to do so when I move to
1.4, but I haven't<br>tested 1.4 yet. It certainly doesn't appear to have asynchronous play.<br><br>Please try applying the last patch listed under that bug (head-v4). You<br>may need to apply quite a bit of it by hand, as I expect the patch doesn't
<br>apply cleanly any more.<br><br>If it fixes your problem (as I expect it will), I can only suggest you do<br>as I do, and keep your own working version of app_meetme.c.<br><br>Something else that I found helped enormously was another patch that was
<br>too late to be included in 1.2 (pity).<br><br>You can find it at bug 5374: <a href="http://bugs.digium.com/view.php?id=5374">http://bugs.digium.com/view.php?id=5374</a><br><br>There are various patches there, but the one I find best, and include in
<br>all 1.2 systems that I build, is called 2005-10-04-3-asynchronous.patch<br><br>It is the channel.c mods that are important. The changes to app_milliwatt,<br>app_sms and app_chanspy will only matter if you use those modules.
<br><br>> Any ideas?<br>><br>> Thanks in advance!<br><br>Hope this helps. Please let the list know how you get on with the patches.<br><br>Cheers<br>Tony<br>--<br>Tony Mountifield<br>Work: <a href="mailto:tony@softins.co.uk">
tony@softins.co.uk</a> - <a href="http://www.softins.co.uk">http://www.softins.co.uk</a><br>Play: <a href="mailto:tony@mountifield.org">tony@mountifield.org</a> - <a href="http://tony.mountifield.org">http://tony.mountifield.org
</a><br><br>_______________________________________________<br><br>Sign up now for AstriCon 2007! September 25-28th. <a href="http://www.astricon.net/">http://www.astricon.net/</a><br><br>--Bandwidth and Colocation Provided by
<a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev
</a><br></blockquote></div><br><br clear="all"><br>-- <br>--------------<br>Paulo Garcia<br>Pika Technologies Inc