Some weeks ago I wrote about a buffer overflow in app_conference Asterisk application when more than 160 samples per frame were received. I showed how the overflow could be fixed using Asterisk smoothers interface. Two days ago I got an e-mail from a guy in Germany ( Tom ), who had a crash in app_conference and found my blog googling about it. I send him the modified version of app_conference with my fix. Even when Asterisk stopped crashing, audio from chan_mISDN channel going to SIP channel was jittering. After adding some debugging messages to app_conference I sent him a new member.c file so he could try it and send me the resulting logs ( I had no access to his server ). The logs showed that chan_mISDN generated frames with multiple amount of samples, is not that odd? The first voice frame on the call had 640 samples encoded with ALAW ( hence 640 bytes ), that first frame was causing Asterisk crash because of the overflow I showed in my other app_conference post. But what was causing the jitter? Well, if more samples than expected can cause an overflow, what does less samples than expected can cause? yes, jitter. app_conference assume 160 samples per frame, because of 20ms RTP packeting being so common and 8000 samples per second being a telephony standard. So, receiving more samples cause overflow, and receiving less of 160 samples cause the mixing of the audio to be incomplete (zeros in the remaining mix buffer), hence, audio with jitter. As I said, chan_misdn generated frames with different amount of samples, however, most of the audio frames (99%) were being received with 120 samples, and a few ones with less than that.
I was tempted to make a simple buffering in app_conference to queue an audio frame until enough samples were received to mix the audio, however, a quick non-code fix was achieved by configuring misdn-init.conf to generate 240 samples. That configuration along with the use of Asterisk smoothers worked like a charm 🙂
I think I will join iax-devel mailing list to discuss this issue with app_conference developers and possibly integrate a final fix for this issues with more/less samples than expected. I saw code in app_conference that was trying to use smoothers, however the last time I checked it was disabled for some reason.
By the way, Tom nicely offered me some German beer for help with that issue.