Fix a bug in interruption metrics
The reported audio interruption metrics are too high. If GetAudio
calls start before the first packets are arriving, and the sample rate
of the encoded audio is different from the one used to initialize
NetEq (default 16 kHz), the initial silent period of GetAudio calls
will be reported as an interruption.
Modifying a unit test to trigger the bug, and make sure it won't come
back.
Bug: webrtc:11094, b/144567257
Change-Id: Id540422cb7f35d3bef68b9e7c03c6e7c8bdb8d97
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159980
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29831}
diff --git a/modules/audio_coding/neteq/neteq_impl.cc b/modules/audio_coding/neteq/neteq_impl.cc
index b6f5971..feabb37 100644
--- a/modules/audio_coding/neteq/neteq_impl.cc
+++ b/modules/audio_coding/neteq/neteq_impl.cc
@@ -2031,6 +2031,8 @@
assert(fs_hz == 8000 || fs_hz == 16000 || fs_hz == 32000 || fs_hz == 48000);
assert(channels > 0);
+ // Before changing the sample rate, end and report any ongoing expand event.
+ stats_->EndExpandEvent(fs_hz_);
fs_hz_ = fs_hz;
fs_mult_ = fs_hz / 8000;
output_size_samples_ = static_cast<size_t>(kOutputSizeMs * 8 * fs_mult_);