We do not allow blocking call from the worker thread, but on Android the worker thread may stop/join a SignalThread, which hits the assert.
AssertBlockingIsAllowedOnCurrentThread is used to make sure a thread does not do Invoke, so check that in Thread::Join does not seem to add much value.
BUG=3857
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7308 4adac7df-926f-26a2-2b94-8c16560cd09d
> Remove the different block lengths in ns_core
>
> This CL has bit-exact output.
>
> What it does:
> * Remove the blockLen10Ms, as it is hardcoded to be equal to blockLen.
> * This makes outLen to be always zero, so it can be removed too.
> * It also avoids the need to have an outBuf, because it is not used, so it is also removed
> * Replaced blockLen10Ms by blockLen everywhere, since they were hardcoded to be equal.
> * We don't need to check if outLen is zero, because it always is, so it was removed.
> * Of course, the outBuf needs no initial set or copying around, because it is not used.
>
> BUG=webrtc:3811
> R=bjornv@webrtc.org, kwiberg@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/30539004TBR=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26629004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7306 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL has bit-exact output.
What it does:
* Remove the blockLen10Ms, as it is hardcoded to be equal to blockLen.
* This makes outLen to be always zero, so it can be removed too.
* It also avoids the need to have an outBuf, because it is not used, so it is also removed
* Replaced blockLen10Ms by blockLen everywhere, since they were hardcoded to be equal.
* We don't need to check if outLen is zero, because it always is, so it was removed.
* Of course, the outBuf needs no initial set or copying around, because it is not used.
BUG=webrtc:3811
R=bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/30539004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7297 4adac7df-926f-26a2-2b94-8c16560cd09d
r7049 added some unnecessary casts ("return 0" -> "return static_cast<uint16_t>(0)"). r7123 converted these to "return 0u". The original impetus for this was to eliminate type conversion warnings. However, the 'u's are unnecessary; Visual Studio can return "0" from a function returning an unsigned value without producing a warning. The real reason for the original warnings was that the code was returning -1 from a function returning an unsigned value, which does need a cast; the -1s were eliminated before the above two revisions landed.
Also reverse the order of some conditionals to prevent possible underflow.
While the underflow wouldn't have changed the behavior of the code, it's easier
to reason about the code when such underflow can't happen, and possibly safer
against future modifications as well.
BUG=3663
TEST=none
R=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22599004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7296 4adac7df-926f-26a2-2b94-8c16560cd09d
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
