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
Previously if thread A->Send is called on thread B, B->ReceiveSends will be called, which enables an arbitrary thread to invoke calls on B while B is wait for A->Send to return. This caused mutliple problems like issue 3559, 3579.
The fix is to limit B->ReceiveSends to only process requests from A.
Also disallow the worker thread invoking other threads.
BUG=3559
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15089004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7290 4adac7df-926f-26a2-2b94-8c16560cd09d
This attenuates the noise pumping generated from the NS adapting to the AEC comfort noise.
When there is echo present the AEC suppresses it and adds comfort noise. This is underestimated on purpose to avoid adding more than the original background noise. The NS has to be called after the AEC, because every non-linear processing before it can ruin its performance. Therefore the noise estimation can adapt to this comfort noise, making it less aggressive and generating noise pumping.
By putting the noise estimation analysis stage from the NS before the AEC, this effect can be avoided. This has been tested manually on recordings where noise pumping was present: Two long recordings done in our team by bjornv and kwiberg plus the most noisy (5) recordings in the QA set.
On the other hand, one risk of doing this is to not adapt to the comfort noise and therefore suppress too much. As verified in the tested files, this is not a problem in practice.
BUG=webrtc:3763
R=andrew@webrtc.org, bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24679004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7289 4adac7df-926f-26a2-2b94-8c16560cd09d
webrtc did not build if AGC_DEBUG was turned on. This CL fixes that. Has no impact on performance since it is development/debug code.
* Name change to WEBRT_AGC_DEBUG_DUMP
* Added build flag agc_debug_dump to .gypi
* Added missing "%d" in printf at two places
* Some line length related style changes
Tested audioproc and modules_unittests with GYP_DEFINES=agc_debug_dump=1 webrtc/build/gyp_webrtc
BUG=N/A
TESTED=locally and trybots
R=aluebs@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31429004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7271 4adac7df-926f-26a2-2b94-8c16560cd09d
The reason why ApmTest.Process breaks on Android is that two metrics over counts. I decided to add an offset and a different slack to the EXPECT_NEAR() calls that are affected. I think this is a reasonable approach since we have no more than two failing metrics. If any feature change that will make another metric fail, we should go back to the desk and find another way of solving this.
BUG=114
TESTED=locally on Nexus 7 and trybots
R=aluebs@webrtc.org, andrew@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26509004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7268 4adac7df-926f-26a2-2b94-8c16560cd09d
This time reverts the Cl that actually broke the tests. Got the wrong rev before. :/
BUG=3520
TESTED=Locally with CHECKOUT_SOURCE_ROOT=`pwd` build/android/test_runner.py gtest -s modules_unittests --gtest_filter=AcmReceiverBitExactness.8kHzOutput --verbose --isolate-file-path=webrtc/modules/modules_unittests.isolate
TBR=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26579004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7264 4adac7df-926f-26a2-2b94-8c16560cd09d
In order to maintain test coverage for the old API (AudioCodingModule)
during the transition period, the old test was copied to
AcmReceiverTestOldApi.
Modified and extended AudioCoding and the implementation to make the
test compile and run.
Created a converter method from new to old config struct
BUG=3520
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31409004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7259 4adac7df-926f-26a2-2b94-8c16560cd09d
The converted tests are:
AcmIsacMtTest
AcmReceiverBitExactness
AcmSenderBitExactness
AudioCodingModuleMtTest
AudioCodingModuleTest
In order to maintain test coverage for the old API (AudioCodingModule)
during the transition period, the old tests were copied and given the
suffix OldApi:
AcmIsacMtTestOldApi
AcmReceiverBitExactnessOldApi
AcmSenderBitExactnessOldApi
AudioCodingModuleMtTestOldApi
AudioCodingModuleTestOldApi
BUG=3520
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23719004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7258 4adac7df-926f-26a2-2b94-8c16560cd09d
Before this change it could happen that a large jump in timestamp (a
jump not correlated to wall-clock change) caused the audio to go silent
without recovering. The reason was that all incoming packets after the
jump were considered too old compared to the last decoded packet, and
were deleted. With CL changes two things:
1. If the only available packet in the buffer is an old packet, NetEq
will do Expand instead of immediate reset. This is to avoid that one
late packet triggers a reset.
2. Old packets are discarded only when the decision to decode a packet
has been taken. This is to allow the buffer to grow and eventually
flush if no decodable packet has been found for some time.
This CL also includes a new unit test for this situation.
BUG=3785
R=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7255 4adac7df-926f-26a2-2b94-8c16560cd09d
Filled the empty analyze API, separating the noise estimation from the process API.
No formatting fixes or extra refactoring has been done, to make the review process easier.
This patch has been tested for bit-exactness over the whole QA set in every aggressiveness.
BUG=webrtc:3811
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/27549004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7243 4adac7df-926f-26a2-2b94-8c16560cd09d
