Hi, I've been away for the Tuesday and Wednesday so haven't been able to look into this at all but I'm trying to get to the bottom of the remaining problems although I still don't have a very good grasp on the code.
Did you manage to find anything unusual in the trace that I previously provided? Any assistance would be appreciated as this is a fairly urgent problem for me. I have seen other comments also describing this problem so I'm not the only one to suffer from this. Is there anything else I can do to help? Thanks, Alex -----Original Message----- From: Alexander Boreham [mailto:[EMAIL PROTECTED] Sent: 16 July 2007 09:56 To: Alexander Chemeris Cc: [email protected] Subject: Re: [sipxtapi-dev] Silence on Windows Minimise / SipXmedia MpdSip xPcma::decodeIn fun ction drops RTP Packets Hi, I've resent this as it didn't get through on Friday. Apologies if you happen to find an extra one in your mailbox. I've attached another trace after applying your patch. It looks like all the push results are OS_SUCCESS. I can't see any errors. I'm not very sure of this code yet but it looks to me like frameIncrement increases the mNextPullTimerCount value by 80. As mNextPullTimerCount has increased by 80 I think that we have moved to the next frame processing cycle. It's very possible I've misunderstood this question however. Thanks, Alex -----Original Message----- From: Alexander Chemeris [mailto:[EMAIL PROTECTED] Sent: 13 July 2007 14:27 To: Alexander Boreham Cc: [email protected] Subject: Re: [sipxtapi-dev] Silence on Windows Minimise / SipXmedia MpdSip xPcma::decodeIn fun ction drops RTP Packets On 7/13/07, Alexander Boreham <[EMAIL PROTECTED]> wrote: > As I understand it, if a difference is negative then we return 1 and play > it. If it's positive then we return 0 and play it later. We can see in this > trace that we start with a set of negative differences. I then reproduce my > problem by performing a sequence of minimize/maximize operations on any > windows. We see the difference gradually increases until it fluctuates > around the zero mark. At this point we should still be okay, as long as some > differences are negative. Later on, around line 2400, we find that the > differences are all positive. At this point we only ever return 0 from our > decodein function and therefore we find that we have no audio being played. >From your log I see that packets are not returned to dejitter, starting from packet with timestamp 2028584216 (second attempt). This could mean, that dejitter is full. Could you print out pushStatus value from new patch? One thing unclear for me form your logs is why does it continue pulling from dejitter after it got diff>0? That is it had to stop pulling after 2028582776, but it continue and pull 2028582936 from dejitter too. Or is it done on the next frame processing cycle? Could you clarify this? rtpTimestamp=2028582776, mNextPullTimerCount=2028582696, diff=80. rtpTimestamp=2028582936, mNextPullTimerCount=2028582776, diff=160. rtpTimestamp=2028582776, mNextPullTimerCount=2028582856, diff=-80. rtpTimestamp=2028582936, mNextPullTimerCount=2028582856, diff=80. rtpTimestamp=2028583096, mNextPullTimerCount=2028582936, diff=160. rtpTimestamp=2028582936, mNextPullTimerCount=2028583016, diff=-80. -- 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/
