Ensure adjusted "known delay" doesn't drop below zero.

The untrusted delay mode provides an option to reduce the "known delay"
parameter passed down to the core AEC. This is necessary to handle the
very low latencies observed with the Chromium audio backend on Mac.

Prior to this change, it was possible to pass a negative value. The AEC
produced good output in practice, but it turned out this tripped a
heretofore unnoticed assert in ProcessBlock().

This change avoids the assert, and maintains the good output across a
set of Mac recordings. Bit-exact in some cases, and in the remaining,
quickly converging to identical output.

The assert was hit on the last webrtc roll in Chromium in
content_browsertests on Mac.

Corresponds to:
https://chromereviews.googleplex.com/9960013

TBR=bjornv
TESTED=Verified locally that "content_browsertests
--gtest_filter=WebrtcBrowserTest.*"" passes.

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

git-svn-id: http://webrtc.googlecode.com/svn/trunk@4886 4adac7df-926f-26a2-2b94-8c16560cd09d
This commit is contained in:
andrew@webrtc.org 2013-10-01 01:12:25 +00:00
parent fd11bbfb56
commit 8e2f9bce71

View File

@ -814,13 +814,18 @@ static void ProcessExtended(aecpc_t* self, const int16_t* near,
EstBufDelayExtended(self);
for (i = 0; i < num_frames; ++i) {
{
// |delay_diff_offset| gives us the option to manually rewind the delay on
// very low delay platforms which can't be expressed purely through
// |reported_delay_ms|.
WebRtcAec_ProcessFrame(self->aec, &near[FRAME_LEN * i],
&near_high[FRAME_LEN * i], self->knownDelay + delay_diff_offset,
&out[FRAME_LEN * i], &out_high[FRAME_LEN * i]);
const int adjusted_known_delay =
WEBRTC_SPL_MAX(0, self->knownDelay + delay_diff_offset);
for (i = 0; i < num_frames; ++i) {
WebRtcAec_ProcessFrame(self->aec, &near[FRAME_LEN * i],
&near_high[FRAME_LEN * i], adjusted_known_delay,
&out[FRAME_LEN * i], &out_high[FRAME_LEN * i]);
}
}
}