Audio bursts when using Conference Bridge

[Dominik Ridjic <dominik.ridjic@xxxxxxxxx>]

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@xxxxxxxxxxx: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@xxxxxxxxxxx: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@xxxxxxxxxxx: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@xxxxxxxxxxx: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@xxxxxxxxxxx: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@xxxxxxxxxxx: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@xxxxxxxxxxx: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@xxxxxxxxxxx: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@xxxxxxxxxxx: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@xxxxxxxxxxx: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

_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org