Leveraging the skew in API call order to a boost AEC3 signal realignment
This CL resets the AEC3 realignment functionality when a significant and persistent skew in the number of render and capture API calls is detected. Bug: chromium:811658,webrtc:8879 Change-Id: Ib5c727b38f427da2a7d25eac7c939a17bdaabe74 Reviewed-on: https://webrtc-review.googlesource.com/52260 Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org> Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org> Cr-Commit-Position: refs/heads/master@{#21997}
This commit is contained in:
@ -101,6 +101,7 @@ void BlockProcessorImpl::ProcessCapture(
|
||||
if (!capture_properly_started_) {
|
||||
capture_properly_started_ = true;
|
||||
render_buffer_->Reset();
|
||||
delay_controller_->Reset();
|
||||
}
|
||||
} else {
|
||||
// If no render data has yet arrived, do not process the capture signal.
|
||||
@ -213,6 +214,7 @@ void BlockProcessorImpl::BufferRender(
|
||||
RenderDelayBuffer::BufferingEvent::kNone);
|
||||
|
||||
render_properly_started_ = true;
|
||||
delay_controller_->LogRenderCall();
|
||||
}
|
||||
|
||||
void BlockProcessorImpl::UpdateEchoLeakageStatus(bool leakage_detected) {
|
||||
|
||||
Reference in New Issue
Block a user