Sharing one observation that may or may not be relevant to the original problem.
I’ve been curious about the behavior of Asterisk/app_rpt during underruns of various kinds. Earlier in this thread there was some speculation about what the system does when an audio frame goes missing. I’m testing that scenario from the perspective of the network (i.e. IAX network frame missing) and the USB interface (i.e. underrun causes a USB frame to get missed).
In my tests of the IAX (network) case it appears that the system interpolates the missing frame. The picture below shows what it looks/sounds like when an IAX frame goes missing. It shows a pure sinusoid (400 Hz test tone) during most of the test. However, the 20ms gap shaded area in the middle shows the period of the single missing frame. During this interval we see what appears to be a continuation of the test tone, but with a linear ramp down of the amplitude and a phase discontinuity at the start/end of the 20ms “gap.” Once the data stream resumes the tone goes back to normal. There is no silence in this period, only an audible pop which I’m assuming is a result of the phase change.
Longer gaps show the same behavior out to about 5 missing frames, at which point the amplitude had decayed away.
My Test Setup
My test node opens an IAX call to an ASL3 server and injects a synthetic tone. I’ve modified my test node to route every 100th outbound audio mini-frame to the wrong address. That equates to a dropped frame every 2 seconds. I listen to the audio (and record) using a second node dialed to the same server.
Explanation of This Behavior (My Guess)
I think what I’m seeing/hearing is the normal function of the packet loss concealment (PLC) feature of Asterisk. PLC is designed to fill any sudden gaps in an attempt to improve audio quality. The reason the 20ms “gap” contains the 400 Hz tone is that the PLC algorithm fills gaps with copies of earlier audio frames. The amplitude ramp-down is designed to “smooth” the transition in and out of the gap period and to limit ringing in the case of a longer gap. Unfortunately, this simple algorithm doesn’t match phase. A very similar (same?) PLC algorithm is described in detail in the G.711 documentation.
The USB version of this test is pretty interesting. I’ll share a write-up when I’m finished.