In practice, we have been doing this since time immemorial, but have
relied on the user to do the downmixing (first voice engine then
Chromium). It's more logical for this burden to fall on AudioProcessing,
however, who can be expected to know that this is a reasonable approach
for AEC. Permitting two render channels results in running two AECs
serially.
Critically, in my recent change to have Chromium adopt the float
interface:
https://codereview.chromium.org/420603004
I removed the downmixing by Chromium, forgetting that we hadn't yet
enabled this feature in AudioProcessing. This corrects that oversight.
The change in paths hit by production users is very minor. As commented
it required adding downmixing to the int16_t path to satisfy
bit-exactness tests.
For reference, find the ApmTest.Process errors here:
https://paste.googleplex.com/6372007910309888
BUG=webrtc:3853
TESTED=listened to the files output from the Process test, and verified
that they sound as expected: higher echo while the AEC is adapting, but
afterwards very close.
R=aluebs@webrtc.org, bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31459004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7292 4adac7df-926f-26a2-2b94-8c16560cd09d
In r6591 a shift macro was removed affecting AECM. In addition to that change a bug was fixed. The fix added a few voice_counts in ApmTest.Process.
This CL updates the reference file, even though it is not used in practice since the test is currently turned off for Android (where AECM is used).
BUG=3672
TESTED=locally
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14089004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6868 4adac7df-926f-26a2-2b94-8c16560cd09d
