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:
parent
532531b656
commit
1ff218fac3
@ -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;
|
||||
}
|
||||
|
Loading…
x
Reference in New Issue
Block a user