We're setting up a conference bridge as follows: (canned wav file) --> chrome --(g722)--> FreeSWITCH conference --(linear PCM)--> c++ app What we are seeing is that FreeSWITCH is inserting 20 ms of silence into the linear PCM output. It does not drop any audio - it is just inserting extra silence. On some traces we see ~1 out of every 100 output audio packet as silence. There is no regular cadence for the insertion. We are able to verify this in two ways: 1. When we look at the linear PCM tcpdump trace, we can identify silence because it's all 0xff. 2. We convert both the g722 and linear PCM into wav files. This is how we observe that no audio is dropped, just 20ms of silence added. The linear PCM wav file adds 20ms of audio and falls behind the g722 audio. We look at the pacing from the tcpdump and chrome is pacing every 20ms. FreeSWITCH, likewise, is also producing at 20ms intervals. We did try turning on the jitter buffer in FreeSWITCH and now see mitigated packets instead of silence, so that did not fix the issue. We'll probably turn off PLC next as mitigated packets are not easily identifiable. After reading https://github.com/signalwire/freeswitch/issues/735 I went back and looked at an old trace and it does appear that we see silence in the output linear PCM ~50-70ms after getting an RTCP packet from chrome. It's not 1:1; in the trace I looked at we had 44 rtcp packets, but only 20 silent packets, but for every silent packet we see an RTCP packet 50-70ms earlier. I hope to get more traces to verify this after turning PLC off. Environment: FreeSWITCH version 1.10.3, running inside a container on bare metal. This is reproducible running a single conference with two participants - no loading. We are turning off encryption in Chrome so we can decode the g722 (no dtls/srtp) and feeding chrome a canned wav file, so we can compare audio. Has anyone else seen this issue? Any suggestions on how to start debugging? I'm trying to trace through read_rtp_packets() in switch_rtp.c, but am a bit lost and not sure if that is where I should start. This issue is severely degrading our audio quality measurements so its causing a lot of headaches for us at the moment.