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
decodeIn_handling.rev2.patch
Description: Binary data
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
