For this problem, I have (manually) applied the patch XMR-70 http://track.sipfoundry.org/browse/XMR-70
There is a ZIP file with a Non Windows Message Queue. This NWMQ is then used in place of the windows message queue in the speaker thread. This solved the problem for me. stipus ----- Original Message ----- From: "Alexander Boreham" <[EMAIL PROTECTED]> To: "Alexander Chemeris" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Friday, July 13, 2007 11:28 AM Subject: Re: [sipxtapi-dev] Silence on Windows Minimise / SipXmediaMpdSip xPcma::decodeIn fun ction drops RTP Packets > Hi Alexander, > > Many Thanks for your sharp response on this. I've applied your patch and it > does help with our issue but doesn't completely resolve it. I haven't had a > chance to trace the new code yet but it seems like what we've done is > postpone the issue. > > Previously I would find that the first time I minimized any window the > sounds would cut off. Now I can perform 10 or so minimize and maximize > operations before the sound cuts off and toggles back on with each minimize > and maximize. > > So in summary it's better now but still not perfect. > > I'll try to take a trace as I did before and see what I find. > > Again, many thanks for your effort here. > > Regards, > Alex > > -----Original Message----- > From: Alexander Chemeris [mailto:[EMAIL PROTECTED] > Sent: 12 July 2007 21:29 > To: Alexander Boreham > Cc: [email protected] > Subject: Re: [sipxtapi-dev] Silence on Windows Minimise / SipXmedia > MpdSipxPcma::decodeIn fun ction drops RTP Packets > > Hi, > > On 7/12/07, Alexander Boreham <[EMAIL PROTECTED]> wrote: > > It looks like there is an issue in the MpdSipxPcma::decodeIn function. The > > same presumably applies to MpdSipxPcmu::decodeIn. The error is around the > > handling of the following code: > > > > <skip> > > > > Thank you for discovering this bug. Jitter buffer part of sipXmediaLib > is known to be error prone and is waiting for a good cleanup/update/rewrite. > This is a part of code with really weird logic. I've already fixed > many bugs in it, > but seems not all of them. And I to rewrite it from scratch, adopting one > of existing JiterBuffers (speex, or any else) or writing our own with better > structured and documented one. > > Could you test attached patch and report result? > > As far as I see it, problem you've pointed out is caused by the fact that > decodeIn() return value is not handled properly by MprDecode. If decodeIn() > returns 0, RTP packet should remain in buffer, so it will be processed next > time again. Current code does not return pulled RTP packet to jitter buffer, > and this break all operation logic. My patch just fix this. > > -- > Regards, > Alexander Chemeris. > > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 > > _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
