These optimizations were originally committed in r6860, but reverted in r6861, since it broke a bitexactness test (ApmTest.Process) in modules_unittests. That test has now been updated in r7149, hence this CL now pass the test.
BUG=3767
TESTED=manually on linux and trybots
TBR=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/25539004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7189 4adac7df-926f-26a2-2b94-8c16560cd09d
When writing to wav files in the low level flag aec_debug_dump incorrect sample rates were used for recordings using rates from 32 kHz and above. This since internally inside the AEC we process the data using 16 kHz. Any upper band is processed and combined later on.
This CL adds the correct sample rate to the recording.
BUG=3359
TESTED=locally on 44.1 kHz recordings on Linux
R=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7182 4adac7df-926f-26a2-2b94-8c16560cd09d
These global arrays are shared amongst all AEC instances, and were at
serious risk of data races. A Chromium TSAN bot recently caught this.
Also move the function pointer selection for optimization to
create-time. (Ideally this would only be done once.)
BUG=chromium:404133,1503
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19069004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6922 4adac7df-926f-26a2-2b94-8c16560cd09d
audio_processing did not compile when aec_untrusted_delay_for_testing=1 was set. The constant kDelayDiffOffsetSamples was declared only for Mac when WEBRTC_UNTRUSTED_DELAY was automatically turned on.
Moving the declaration outside the ifdef makes it build with the flag on for any platform.
BUG=3673
TESTED=locally and trybots
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22049004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6866 4adac7df-926f-26a2-2b94-8c16560cd09d
With GCC 4.9, the MIPS NDK toolchain has been changed to only support 16 spregs by default - the even-numbered ones. This has been changed to support the R6 MIPS architecture. While the old behaviour could be restored by adding "-modd-spreg", this would come with a performance hit because the kernel would emulate odd-numbered spregs and missing R2 instructions.
As a result of this change, the functions removed in this CL no longer compile as there are no longer enough spregs for the compiler to assign. So we are removing these functions and they will use the C implementation until the MIPS code is rewritten.
R=andrew@webrtc.org, ljubomir.papuga@gmail.com, pasko@chromium.org
Review URL: https://webrtc-codereview.appspot.com/16159005
Patch from Fabrice de Gans-Riberi <fdegans@chromium.org>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6797 4adac7df-926f-26a2-2b94-8c16560cd09d
Was causing warnings in Chromium such as:
warning C4742: 'WebRtcAec_overDriveCurve' has different alignment in 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core_sse2.c' and 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core.c': 4 and 16
warning C4744: 'WebRtcAec_overDriveCurve' has different type in 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core_sse2.c' and 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core.c': 'array (260 bytes)' and '__declspec(align(16)) array (260 bytes)'
warning C4742: 'WebRtcAec_weightCurve' has different alignment in 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core_sse2.c' and 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core.c': 4 and 16
warning C4744: 'WebRtcAec_weightCurve' has different type in 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core_sse2.c' and 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core.c': 'array (260 bytes)' and '__declspec(align(16)) array (260 bytes)'
BUG=https://code.google.com/p/chromium/issues/detail?id=336620R=andrew@webrtc.org, cd@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15869004
Patch from Sebastien Marchand <sebmarchand@chromium.org>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6525 4adac7df-926f-26a2-2b94-8c16560cd09d
Several tests were disabled in r6325 and r6326. Also, see issue 3445. This CL fixes the remaining four of the audio_processing related ones. Affects the tests:
- SystemDelayTest.CorrectDelayAfterStableBufferBuildUp
- SystemDelayTest.CorrectDelayDuringDrift
- SystemDelayTest.ShouldRecoverAfterGlitch
- ApmTest.EchoCancellationReportsCorrectDelays
The tests assumes reported delays are used, which now is explicitly set.
BUG=3445
TESTED=trybots
R=aluebs@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19769004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6489 4adac7df-926f-26a2-2b94-8c16560cd09d
Each audio processing step is given a pointer to an AudioBuffer, where
it can read and write int data. This patch adds corresponding
AudioBuffer methods to read and write float data; the buffer will
automatically convert the stored data between int and float as
necessary.
This patch also modifies the echo cancellation step to make use of the
new methods (it was already using floats internally; now it doesn't
have to convert from and to ints anymore).
(The reference data to the ApmTest.Process test had to be modified
slightly; this is because the echo canceller no longer unnecessarily
converts float data to int and then immediately back to float for each
iteration in the loop in EchoCancellationImpl::ProcessCaptureAudio.)
BUG=
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/18399005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6138 4adac7df-926f-26a2-2b94-8c16560cd09d
These changes are currently not used in webrtc/ but helps in using the delay estimator.
* The last_delay_quality() is updated with respect to robust_validation and changed to return float.
* Tests are updated wtih respect to above.
* Adds the possibility to make a soft reset based on external circumstances like a known delay shift has been made.
* The soft reset change the lookahead dynamically. An API to ask for current lookahead has been added as well.
BUG=N/A
TESTED=trybots, modules_unittest
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10409004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5761 4adac7df-926f-26a2-2b94-8c16560cd09d
I don't believe I've witnessed this "feature" ever provide a benefit,
and have now collected some evidence of its harm when using the
extended filter mode. It can cause erroneous resets in two cases:
1. Some preprocessing noise suppression is enabled in the system (i.e.
"audio enhancements") that push the noise floor very low, possibly to
zero. If the filter is non-zero this condition can be triggered very
easily, and erroneously.
2. Non-zero energy in the filter before the peak impulse response can
cause a slight (and harmless) "pre-echo" in the error signal. This
becomes more significant as the peak is set further back in the filter.
This effect can cause needless resets during echo onsets.
In short, this isn't a great criterion for filter reset and has the
potential to cause serious harm. Ideally we would remove it entirely,
but in the interests of safety, can start with the extended mode.
BUG=1261
R=aluebs@webrtc.org, bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/3959004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5159 4adac7df-926f-26a2-2b94-8c16560cd09d
