Context
We observed that speex jitter buffer suffered from a "stuck" delay evaluation in very difficult network scenarios.
When network delay/jitter have huge oscillations and then go back to a stable state, the buffer might potentially end up in a status where it's unable to update its internal delay anymore.
The effect is that even in optimal conditions, the buffer will add a de-jittering delay. This can be tested by conditioning the network link and observing the buffer-in value through the Admin API. The expected result is a low buffer-in when network conditions are restored.
As a consequence, we implemented a workaround in the audiobridge some time ago that once in a while checked the buffer length did not exceed a JITTER_BUFFER_MAX_PACKETS length. If that happened, we requested a jitter buffer reset.
Findings
We discovered that this behavior could be triggered by frequent calls to jitter_buffer_delay_update under high network variance. That function basically recalculates the buffer internal delay.
By default the buffer is auto-adjusting and the delay is updated anytime a jitter_buffer_tick is invoked. We issue a buffer tick any time a participant audio packet must be added to the mix, so every ~20ms we indirectly update the jitter internal delay. By collecting examples of how the library is used, we found out that many implementations switched to manual updates through condition-related jitter_buffer_delay_update calls.
The PR
This patch is twofold:
1) in speex library code: add an interface to set an internal max length in place of the hard-coded 200.
2) in audiobridge code: it sets buffer max size to JITTER_BUFFER_MAX_PACKETS, disables automatic buffer delay adjusting and performs a jitter_buffer_delay_update every JITTER_BUFFER_MAX_PACKETS ticks.
With these changes we are unable to reproduce the issue but given its nature and the difficult steps for reproducing it, we'd like to collect some feedback from people interested in improving the audiobridge experience.
Context We observed that speex jitter buffer suffered from a "stuck" delay evaluation in very difficult network scenarios. When network delay/jitter have huge oscillations and then go back to a stable state, the buffer might potentially end up in a status where it's unable to update its internal delay anymore. The effect is that even in optimal conditions, the buffer will add a de-jittering delay. This can be tested by conditioning the network link and observing the
buffer-invalue through the Admin API. The expected result is a lowbuffer-inwhen network conditions are restored. As a consequence, we implemented a workaround in the audiobridge some time ago that once in a while checked the buffer length did not exceed aJITTER_BUFFER_MAX_PACKETSlength. If that happened, we requested a jitter buffer reset.Findings We discovered that this behavior could be triggered by frequent calls to
jitter_buffer_delay_updateunder high network variance. That function basically recalculates the buffer internal delay. By default the buffer is auto-adjusting and the delay is updated anytime ajitter_buffer_tickis invoked. We issue a buffer tick any time a participant audio packet must be added to the mix, so every ~20ms we indirectly update the jitter internal delay. By collecting examples of how the library is used, we found out that many implementations switched to manual updates through condition-relatedjitter_buffer_delay_updatecalls.The PR This patch is twofold: 1) in speex library code: add an interface to set an internal max length in place of the hard-coded 200. 2) in audiobridge code: it sets buffer max size to
JITTER_BUFFER_MAX_PACKETS, disables automatic buffer delay adjusting and performs ajitter_buffer_delay_updateeveryJITTER_BUFFER_MAX_PACKETSticks.With these changes we are unable to reproduce the issue but given its nature and the difficult steps for reproducing it, we'd like to collect some feedback from people interested in improving the audiobridge experience.