Hi, We are using PJSIP for many years now both within Android and iOS applications (currently version 2.8) and notice with one of our customers an issue due to the "bursty" nature of the Conference Bridge whenever we send audio over his media gateway (which goes to the PSTN network). With Wireshark we could determine that both apps send multiple packets of the audio stream out at around roughly 130-150ms, then apparently buffer and send the buffered audio out again 130-150ms. This presents a problem to us because this customer cannot change his media gateway settings (like Jitter buffer) due to all the other applications running on it being affected by it. When we use the Audio Switch Board instead the app will send out packets at exactly every 20ms, sadly we cannot use this due to requiring conference call capabilities. What I've gathered from this PJSIP logs I've captured is (the log line "conference.c put_frame" was inserted by myself, the others are from PJSIP): 15:19:07.769 conference.c !put_frame 15:19:07.789 conference.c put_frame 15:19:07.808 conference.c put_frame 15:19:07.828 conference.c put_frame 15:19:07.848 conference.c put_frame 15:19:07.861 conference.c !- clock - 15:19:07.861 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.861 conference.c resample, input count=160 15:19:07.861 conference.c rx buffer size is now 3040 15:19:07.862 conference.c - clock - 15:19:07.862 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.862 conference.c resample, input count=160 15:19:07.862 conference.c rx buffer size is now 2880 15:19:07.863 conference.c - clock - 15:19:07.863 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.863 conference.c resample, input count=160 15:19:07.864 conference.c rx buffer size is now 2720 15:19:07.864 conference.c - clock - 15:19:07.864 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.864 conference.c resample, input count=160 15:19:07.865 conference.c rx buffer size is now 2560 15:19:07.866 conference.c - clock - 15:19:07.866 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.866 conference.c resample, input count=160 15:19:07.866 conference.c rx buffer size is now 2400 15:19:07.868 conference.c !put_frame 15:19:07.888 conference.c put_frame 15:19:07.908 conference.c put_frame 15:19:07.928 conference.c put_frame 15:19:07.948 conference.c put_frame 15:19:07.960 conference.c !- clock - 15:19:07.961 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.961 conference.c resample, input count=160 15:19:07.962 conference.c rx buffer size is now 2240 15:19:07.963 conference.c - clock - 15:19:07.963 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.963 conference.c resample, input count=160 15:19:07.963 conference.c rx buffer size is now 2080 15:19:07.964 conference.c - clock - 15:19:07.964 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.964 conference.c resample, input count=160 15:19:07.964 conference.c rx buffer size is now 1920 15:19:07.965 conference.c - clock - 15:19:07.965 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.965 conference.c resample, input count=160 15:19:07.966 conference.c rx buffer size is now 1760 15:19:07.966 conference.c - clock - 15:19:07.966 conference.c read_port sip:00436504037030@sipwise.com: count=640 15:19:07.966 conference.c resample, input count=160 15:19:07.967 conference.c rx buffer size is now 1600 15:19:07.969 conference.c !put_frame 15:19:07.990 conference.c put_frame 15:19:08.009 conference.c put_frame 15:19:08.028 conference.c put_frame 15:19:08.049 conference.c put_frame 15:19:08.061 conference.c !- clock - The mic does feed the Conference Bridge which then forwards it to the Adaptive Delay Buffer -> Circular Delay Buffer frames every 20ms as would be expected. But some clock driving the whole thing in the background will only send and empty these buffers (including the one from incoming audio) almost exactly every 100ms. Is there a way to reduce this to maybe 50 or 60ms because I suppose this is being done for a reason (ensuring good audio quality or for CPU performance reasons) I'm thankful if you can help us out here. Also I'm sorry if this is the wrong place to ask, we have bought a Commercial (or alternative) license for you for many years now (the company being Sipwise), but I didn't find a form for commercial support. Best Regards, Dominik Ridjic