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
Analogous to the recent libjingle change: http://cl/54929753-p10.
This supports scoped_ptr<T[]> and scoped_ptr<C, FreeDeleter> rather
than scoped_array and scoped_ptr_malloc respectively.
- Add Chromium's template-based COMPILE_ASSERT. We didn't have this
previously in order to support the macro in C. Instead, move the
existing macro to compile_assert_c.h.
- Additionally copy the move.h and template_util.h depedencies and add
the WARN_UNUSED_RESULT macro.
- Leave scoped_array and scoped_ptr_malloc for now, but mark as
deprecated.
- Remove scoped_ptr foo(NULL) use. The default constructor handles it.
- Remove the now redundant COMPILE_ASSERT from peerconnection_jni.cc.
- Add a CHECK_ARRAY_SIZE macro to rtp_format_vp8_unittest.cc to remove
some repeated code.
TESTED=trybots
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2449005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5015 4adac7df-926f-26a2-2b94-8c16560cd09d
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
Re-land: http://review.webrtc.org/2151007/TBR=bjornv@webrtc.org
Original change description:
This mode extends the filter length from the current 48 ms to 128 ms.
It is runtime selectable which allows it to be enabled through
experiment. We reuse the DelayCorrection infrastructure to avoid having
to replumb everything up to libjingle.
Increases AEC complexity by ~50% on modern x86 CPUs.
Measurements (in percent of usage on one core):
Machine/CPU Normal Extended
MacBook Retina (Early 2013),
Core i7 Ivy Bridge (2.7 GHz, hyperthreaded) 0.6% 0.9%
MacBook Air (Late 2010), Core 2 Duo (2.13 GHz) 1.4% 2.7%
Chromebook Pixel, Core i5 Ivy Bridge (1.8 GHz) 0.6% 1.0%
Samsung ARM Chromebook,
Samsung Exynos 5 Dual (1.7 GHz) 3.2% 5.6%
The relative value is large of course but the absolute should be
acceptable in order to have a working AEC on some platforms.
Detailed changes to the algorithm:
- The filter length is changed from 48 to 128 ms. This comes with tuning
of several parameters: i) filter adaptation stepsize and error
threshold; ii) non-linear processing smoothing and overdrive.
- Option to ignore the reported delays on platforms which we deem
sufficiently unreliable. Currently this will be enabled in Chromium for
Mac.
- Faster startup times by removing the excessive "startup phase"
processing of reported delays.
- Much more conservative adjustments to the far-end read pointer. We
smooth the delay difference more heavily, and back off from the
difference more. Adjustments force a readaptation of the filter, so they
should be avoided except when really necessary.
Corresponds to these changes:
https://chromereviews.googleplex.com/9412014https://chromereviews.googleplex.com/9514013https://chromereviews.googleplex.com/9960013
BUG=454,827,1261
Review URL: https://webrtc-codereview.appspot.com/2295006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4848 4adac7df-926f-26a2-2b94-8c16560cd09d
> Add an extended filter mode to AEC.
>
> This mode extends the filter length from the current 48 ms to 128 ms.
> It is runtime selectable which allows it to be enabled through
> experiment. We reuse the DelayCorrection infrastructure to avoid having
> to replumb everything up to libjingle.
>
> Increases AEC complexity by ~50% on modern x86 CPUs.
> Measurements (in percent of usage on one core):
>
> Machine/CPU Normal Extended
> MacBook Retina (Early 2013),
> Core i7 Ivy Bridge (2.7 GHz, hyperthreaded) 0.6% 0.9%
>
> MacBook Air (Late 2010), Core 2 Duo (2.13 GHz) 1.4% 2.7%
>
> Chromebook Pixel, Core i5 Ivy Bridge (1.8 GHz) 0.6% 1.0%
>
> Samsung ARM Chromebook,
> Samsung Exynos 5 Dual (1.7 GHz) 3.2% 5.6%
>
> The relative value is large of course but the absolute should be
> acceptable in order to have a working AEC on some platforms.
>
> Detailed changes to the algorithm:
> - The filter length is changed from 48 to 128 ms. This comes with tuning
> of several parameters: i) filter adaptation stepsize and error
> threshold; ii) non-linear processing smoothing and overdrive.
> - Option to ignore the reported delays on platforms which we deem
> sufficiently unreliable. Currently this will be enabled in Chromium for
> Mac.
> - Faster startup times by removing the excessive "startup phase"
> processing of reported delays.
> - Much more conservative adjustments to the far-end read pointer. We
> smooth the delay difference more heavily, and back off from the
> difference more. Adjustments force a readaptation of the filter, so they
> should be avoided except when really necessary.
>
> Corresponds to these changes:
> https://chromereviews.googleplex.com/9412014
> https://chromereviews.googleplex.com/9514013
> https://chromereviews.googleplex.com/9960013
>
> BUG=454,827,1261
> R=bjornv@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/2151007TBR=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2296005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4839 4adac7df-926f-26a2-2b94-8c16560cd09d
This mode extends the filter length from the current 48 ms to 128 ms.
It is runtime selectable which allows it to be enabled through
experiment. We reuse the DelayCorrection infrastructure to avoid having
to replumb everything up to libjingle.
Increases AEC complexity by ~50% on modern x86 CPUs.
Measurements (in percent of usage on one core):
Machine/CPU Normal Extended
MacBook Retina (Early 2013),
Core i7 Ivy Bridge (2.7 GHz, hyperthreaded) 0.6% 0.9%
MacBook Air (Late 2010), Core 2 Duo (2.13 GHz) 1.4% 2.7%
Chromebook Pixel, Core i5 Ivy Bridge (1.8 GHz) 0.6% 1.0%
Samsung ARM Chromebook,
Samsung Exynos 5 Dual (1.7 GHz) 3.2% 5.6%
The relative value is large of course but the absolute should be
acceptable in order to have a working AEC on some platforms.
Detailed changes to the algorithm:
- The filter length is changed from 48 to 128 ms. This comes with tuning
of several parameters: i) filter adaptation stepsize and error
threshold; ii) non-linear processing smoothing and overdrive.
- Option to ignore the reported delays on platforms which we deem
sufficiently unreliable. Currently this will be enabled in Chromium for
Mac.
- Faster startup times by removing the excessive "startup phase"
processing of reported delays.
- Much more conservative adjustments to the far-end read pointer. We
smooth the delay difference more heavily, and back off from the
difference more. Adjustments force a readaptation of the filter, so they
should be avoided except when really necessary.
Corresponds to these changes:
https://chromereviews.googleplex.com/9412014https://chromereviews.googleplex.com/9514013https://chromereviews.googleplex.com/9960013
BUG=454,827,1261
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2151007
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4837 4adac7df-926f-26a2-2b94-8c16560cd09d
A new test target named 'modules_integrationtests' is created
and the following test targets were merged into it:
* audio_coding_module_test
* test_fec
* video_coding_integrationtests
* vp8_integrationtests
A couple of other targets were merged into modules_unittests:
* audio_coding_unittests
* audioproc_unittest
* common_unittests
* video_coding_unittests
* video_processing_unittests
* vp8_unittests
I wasn't able to merge audio_decoder_unittests and neteq_unittests due to
conflicts with different defines in these tests.
Some tests that have special requirements aren't merged into
modules_integrationtests yet. I took the opportunity to rename them
since the bot configs will need to be update anyway:
* audio_device_test_api -> audio_device_integrationtests
* video_capture_module_test -> video_capture_integrationtests
* video_render_module_test -> video_render_integrationtests
Exclude files were added for modules_integrationtests to make sure
the memcheck and tsan bots doesn't tests that are too slow
(audio_coding_module_test and vp8_integrationtests were previously
disabled on those bots).
Suppressions for AudioCodingModuleTest needed to be added to get
modules_integrationtests to pass memcheck (even if the test is
excluded from execution).
BUG=1843
TEST=local execution on Linux and trybots (passing except the merged tests of course)
R=andrew@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1656004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4228 4adac7df-926f-26a2-2b94-8c16560cd09d
Run time error message for function WebRtcNsx_PrepareSpectrumNeon(): "Bad access at: 0x4f535c: vst1.16{d16, d17, d18, d19}, [r2], r12"
Cause: "anaLen" was defined as int16_t and should have been read as such in assembly function WebRtcNsx_PrepareSpectrumNeon().
Fix: Changed anaLen's definition to int in the header file instead.
BUG=b/8382174
Review URL: https://webrtc-codereview.appspot.com/1202004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3669 4adac7df-926f-26a2-2b94-8c16560cd09d
