audio_processing/aec: Do not scale target delay at startup when on Android

When running AEC in extended_filter mode there is no startup phase to evaluate the reported system delay values.
Instead we simply use the first value and scale by two to avoid over compensating when synchronizing render and capture.
We don't need to be too accurate since we have extended the filter length.

On Android we use fixed (measured) reported delay values.
There is no need to be extra conservative here, because that is already built-in in the measured value.
In fact, the difference between devices is large and with such an extra conservative approach the true delay can not be caught by the filter length.
With this change we can improve performance on some devices.

BUG=4472
TESTED=offline on recordings from various devices
R=kwiberg@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/49909004

Cr-Commit-Position: refs/heads/master@{#9144}
This commit is contained in:
Bjorn Volcker 2015-05-06 12:08:38 +02:00
parent 532531b656
commit 1ff218fac3

View File

@ -789,9 +789,15 @@ static void ProcessExtended(Aec* self,
// measurement.
int startup_size_ms =
reported_delay_ms < kFixedDelayMs ? kFixedDelayMs : reported_delay_ms;
int overhead_elements = (WebRtcAec_system_delay(self->aec) -
startup_size_ms / 2 * self->rate_factor * 8) /
PART_LEN;
int target_delay = startup_size_ms * self->rate_factor * 8;
#if !defined(WEBRTC_ANDROID)
// To avoid putting the AEC in a non-causal state we're being slightly
// conservative and scale by 2. On Android we use a fixed delay and
// therefore there is no need to scale the target_delay.
target_delay /= 2;
#endif
int overhead_elements =
(WebRtcAec_system_delay(self->aec) - target_delay) / PART_LEN;
WebRtcAec_MoveFarReadPtr(self->aec, overhead_elements);
self->startup_phase = 0;
}