From 76a74e6dc8349b56e5e2a9649daed5c4727bae23 Mon Sep 17 00:00:00 2001 From: Ruslan Burakov Date: Fri, 22 Feb 2019 19:28:02 +0100 Subject: [PATCH] Delay bug during audio receiver stream recreation. For e.g. when audio receiver is recreated during SetRtpExtensionsAndRecreateStream in webrtc_voice_engine.h, the audio minimum delay can't go down. Imagine we set base minimum playout delay when audio receiver stream is created, then its value will be cached, to be applied during recreation. Then SetRtpExtensionsAndRecreateStream is fired, and audio receiver stream is recreated with the cached value, but currently it in the constructor it is used to initialize both base minimum playout delay and minimum playout delay. Which leads to the bug that effective minimum playout delay can't go down anymore as if you set base minimum playout delay to the low value then effective delay use the biggest value which minimum playout delay. This didn't come up during previous trials because of https://webrtc-review.googlesource.com/c/src/+/122280 It was reseting minimum playout delay to 0 asynchronously, that is why you couldn't see this bug. Bug: webrtc:10287 Change-Id: I924446bfcb33ac94f7e5bf987a1868acaf1b0346 Reviewed-on: https://webrtc-review.googlesource.com/c/124000 Reviewed-by: Henrik Lundin Commit-Queue: Ruslan Burakov Cr-Commit-Position: refs/heads/master@{#26832} --- modules/audio_coding/neteq/delay_manager.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/audio_coding/neteq/delay_manager.cc b/modules/audio_coding/neteq/delay_manager.cc index e22a40879e..6147cacb4a 100644 --- a/modules/audio_coding/neteq/delay_manager.cc +++ b/modules/audio_coding/neteq/delay_manager.cc @@ -84,7 +84,7 @@ DelayManager::DelayManager(size_t max_packets_in_buffer, streaming_mode_(false), last_seq_no_(0), last_timestamp_(0), - minimum_delay_ms_(base_minimum_delay_ms_), + minimum_delay_ms_(0), maximum_delay_ms_(0), iat_cumulative_sum_(0), max_iat_cumulative_sum_(0),