>> > Ah okay. In that case increasing PJMEDIA_SOUND_BUFFER_COUNT probably >> > will help. Try with: >> > #define PJMEDIA_SOUND_BUFFER_COUNT 16 >> > in your config_site.h, and if it's okay, experiment with reducing the >> > number until you get comfortable latency. >> >> I had tried that earlier with a value of 12 and tried again (now) with a >> value of 16. But that didn't help much besides the fact that it did >> reduce >> the number of 'overflow'/'underflow' log messages. And I seem to see >> those >> messages as frequently with pjmedia's g711 codec too. >> > > In that case, perhaps you can try with increasing it further to, say, > 32, or even 64 just for the sake of it, and see if it helps. > > The problem seems to be with the sound device, and not with the codec. >>From your log, it looks like the sound device is too bursty (meaning > it calls multiple get_frame() at once and followed by multiple > put_frames()) and the burst level is too high to be accommodated by > pjmedia's default setting, hence we need to increase > PJMEDIA_SOUND_BUFFER_COUNT. > > Well that's my suspicion anyway. > I tried your suggestion and went up to a value of 512. Latency was too high and media quality didn't improve much. However it improved to a level that it seemed that audio frames from the 2 different (G729) calls are "interfering". There were 2-3 of us here and all of us are quite sure that the 2 streams are somehow "interfering". Point to note - only one call is granted mic and speaker at a time which is the last call made. This is happenning and can be seen in the log. 19:28:33.171 conference.c Port 0 (Primary Sound Capture Driver) stop transmitting to port 1 (sip:+18007860404 at 208.109.178.168) 19:28:33.171 strm021ADBC4 Start talksprut.. 19:28:33.171 conference.c Port 4 (sip:+18009363500 at 208.109.178.168) transmitting to port 0 (Primary Sound Capture Driver) 19:28:33.171 conference.c Port 0 (Primary Sound Capture Driver) transmitting to port 4 (sip:+18009363500 at 208.109.178.168) I had first made a call to 18007860404 and then to 18009363500. As seen, it takes 'focus' away from the first call and gives it to the latest (2nd call here) call. Since CPU doesn't look like the issue and increasing PJMEDIA_SOUND_BUFFER_COUNT hasn't helped, maybe something is wrong with our G729 integration. We integrated g729 using g711.c as a 'working example'. It works fine for single g729 calls at a time. Is there anything we should do for integration which is not evident from the g711 source (g711.c)? BTW, we dont use PJMEDIA's plc or vad feature for G729. Regards, Anshuman
