Summary:	ASTERISK-07969: [patch] Jitterbuffer PLC fix for IAX2 channel and other issues with jitterbuffer
Reporter:	Martin Vit (festr)	Labels:
Date Opened:	2006-10-20 07:17:34	Date Closed:	2007-05-15 17:29:42
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/Jitterbuffer
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) patch-translate.c ( 1) sip-adaptive.wav
Description:	Several problems: 1) When transcoding from IAX2 to Zaptel, PLC does not correctly set f->datalen so interpolated frames was thrown because of f->datalen = 0. Attached patch (patch-translace.c) tryes to fix this (tested and works well SIP(gsm) -> zaptel (alaw)) 2) When bridging IAX2 and Zaptel and both channels are ALAW || ULAW there is no transcoding and thus PLC is never used. Solution could be to make wrapper for this? I've forced chan_zap to use SLINEAR, i need PLC :-) 3) Bridging zaptel -> SIP. Adaptive jitterbuffer -> sound is always choppy (see sip-adaptive.wav). Fixed jitterbuffer is working well but without PLC. It seems that transcoding SIP - zaptel is before traversing through framein in translate.c this needs deeper analysis which i'm not capable of.
Comments:	By: Martin Vit (festr) 2006-10-20 21:35:18 i've done more tests (<- Zap <- SIP ) - Sip adaptive jitterbuffer is not working at all. Sound is periodical clicking (its like if you cut every frame to its half size see attached sip-adaptive.wav) - Sip fixed jitter: when using alaw, jittermax = 200 and simulated jitter is from 0 to 200ms, sound is clear. But every other codecs (gsm for ex.) the sound is clear with stable jitter until i turn on jitter simulation (0 ~ 200ms). Sound is choppy. You can test it using virtual ztd-eth zaptel driver for those who have no access to tdm hw or i can provide access to my tests asterisks (ztd-eth). By: Martin Vit (festr) 2006-10-22 17:57:26 the "clicks" with other then a/u-law frames coming from RTP -> SIP -> fixed jitter buffer are when jitter is "shrinking". For example i have 500ms fixed jitter. When increasing jitter from 0ms to 200ms frames are delivered from queue and sound is clean. When decreasing jitter, frames are coming from network faster (differences are sometime about 1ms) and i hear "clicks". Interesting is that alaw and ulaw aren't doing this (x-law is also passing through alawtoslin_frameout) By: Martin Vit (festr) 2006-10-23 04:41:46 All tests i have done has always this setup direction: Analog phone -> E1 -> zaptel -> SIP-Phone (gsm) So SIP channel registered read translation (gsm) so frames was translated before putting to jitter buffer. When few rtp frames are send in burst sound is choppy. I've modified codec setup: *)SIP reads in native formats without translator so frames are delivered to jitter natively *)Zaptel channel register write translator. In this setup sound is perfect. I'm thinking about race condition in trans_pvt structures. When translating frame it is stored in this structure and delivered to jitter buffer which will copy frame from trans_pvt to its own list of frames. If few frames comes in burst (1ms difference) this buffer could be overwritten. But I'm not sure how rtp frames are delivered to translator. Just an idea. By: Steve Murphy (murf) 2006-11-17 14:52:09.000-0600 So, festr, I see your patch to translate.c. Is this all? I can submit this pretty quick, if this is all it takes to solve this bug! By: Martin Vit (festr) 2006-11-17 14:55:58.000-0600 I've made mistake describing different bugs in this one bug. This patch only fixes generic PLC which is not activated at all because of zero datalen. I've no idea how to solve remaining problems. Read my three notes above. By: Steve Murphy (murf) 2006-11-24 11:42:19.000-0600 The supplied patch has been applied to 1.4 via 47992 and applied to trunk via 47995. By: jmls (jmls) 2007-02-11 03:37:48.000-0600 If the patch has been applied, shouldn't this report be closed ? By: Martin Vit (festr) 2007-02-11 04:25:54.000-0600 there are two bugs remaining 2) When bridging IAX2 and Zaptel and both channels are ALAW || ULAW there is no transcoding and thus PLC is never used. Solution could be to make wrapper for this? I've forced chan_zap to use SLINEAR, i need PLC :-) 3) Bridging zaptel -> SIP. Adaptive jitterbuffer -> sound is always choppy (see sip-adaptive.wav). Fixed jitterbuffer is working well but without PLC. It seems that transcoding SIP - zaptel is before traversing through framein in translate.c this needs deeper analysis which i'm not capable of. By: Martin Vit (festr) 2007-05-15 02:55:43 please, close this bug. Zatptel and sip using adaptive jitter is OK now. By: Steve Murphy (murf) 2007-05-15 17:29:41 My pleasure! Wish I could take credit for the fix! Closing this bug.