Fixes issue where WebRTC.Audio.RecordSampleRateOffsetInPercent can report 100% (part II)
See https://webrtc-review.googlesource.com/c/src/+/100241 for part I.
It can happen that recording fail to start but playout works. If that happens, we can
log stats like this:
9-25 15:32:02.023 13903 13948 I audio_device_buffer.cc: (line 414): [REC : 10002msec, 48kHz] callbacks: 0, samples: 0, rate: 0, rate diff: 100%, level: 0
09-25 15:32:02.024 13903 13948 I audio_device_buffer.cc: (line 432): [PLAY: 10002msec, 48kHz] callbacks: 1002, samples: 480960, rate: 48086, rate diff: 0%, level: 0
09-25 15:32:12.028 13903 13948 I audio_device_buffer.cc: (line 414): [REC : 10005msec, 48kHz] callbacks: 0, samples: 0, rate: 0, rate diff: 100%, level: 0
09-25 15:32:12.028 13903 13948 I audio_device_buffer.cc: (line 432): [PLAY: 10005msec, 48kHz] callbacks: 1000, samples: 480000, rate: 47976, rate diff: 0%, level: 0
hence, we log invalid UMA stats for a rate offset of 100%. This change fixes the problem, and in the
case above, we now instead log:
09-25 15:35:56.141 14116 14161 I audio_device_buffer.cc: (line 432): [PLAY: 10011msec, 48kHz] callbacks: 1002, samples: 480960, rate: 48043, rate diff: 0%, level: 0
09-25 15:36:06.151 14116 14161 I audio_device_buffer.cc: (line 432): [PLAY: 10010msec, 48kHz] callbacks: 1002, samples: 480960, rate: 48048, rate diff: 0%, level: 0
09-25 15:36:16.162 14116 14161 I audio_device_buffer.cc: (line 432): [PLAY: 10011msec, 48kHz] callbacks: 1001, samples: 480480, rate: 47995, rate diff: 0%, level: 0
09-25 15:36:26.173 14116 14161 I audio_device_buffer.cc: (line 432): [PLAY: 10011msec, 48kHz] callbacks: 1001, samples: 480480, rate: 47995, rate diff: 0%, level: 0
Bug: b/113648245
Change-Id: Ic8cb71ca049ef24bf68963a81f95d4e5c2282518
Reviewed-on: https://webrtc-review.googlesource.com/101881
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24828}
f1239b5405