[0.x] [audiobridge] jitter buffer: manually update internal delay and set a max size #3353
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 lowbuffer-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-relatedjitter_buffer_delay_update
calls.The PR
This patch is twofold:
JITTER_BUFFER_MAX_PACKETS
, disables automatic buffer delay adjusting and performs ajitter_buffer_delay_update
everyJITTER_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.