It looks to me like we can further reduce the chance of getting into the silent state by applying this patch but at some point we'll still reach it.
I certainly expect to look at this patch as the distortion when performing windows operations isn't suitable for us. However, the potential of reaching a silent state is much worse and I'd be more comfortable resolving this silence first rather than covering it. Thanks, Alex -----Original Message----- From: Alexander Chemeris [mailto:[EMAIL PROTECTED] Sent: 13 July 2007 16:35 To: stipus Cc: Alexander Boreham; [email protected] Subject: Re: [sipxtapi-dev] Silence on Windows Minimise / SipXmediaMpdSip xPcma::decodeIn fun ction drops RTP Packets On 7/13/07, stipus <[EMAIL PROTECTED]> wrote: > 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. This patch is too rough. If I recall correctly, it sets realtime priority for all sipXtapi threads. This is dangerous and in fact does no needed. Only media processing and input/output threads should have high priority. That was the reason to not include this patch in svn. If someone will clean up it, we'll consider applying it to svn. And it fix only problems with window move, but does not touch problems with RTP handling code. So, this problems shuld be solved anyway, or they'll appear again in different conditions (e.g. bad network conditions). -- 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/
