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
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
* Add a RingBuffer typedef.
* Add the ability to force a memcpy by passing a null ptr. In some cases,
we know we want a memcpy. This allows us to skip a potential
intermediate memcpy.
* Add a stress test.
Review URL: https://webrtc-codereview.appspot.com/1111004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3567 4adac7df-926f-26a2-2b94-8c16560cd09d
* Added aec_core_internal.h for private variables.
* Moved aec_t struct to aec_core_internal.h
* Name change aec_t -> AecCore
* Moved additional declarations to aec_core_internal.h
* Tested with audioproc_unittest and trybots
TEST=none
BUG=none
Review URL: https://webrtc-codereview.appspot.com/1117004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3553 4adac7df-926f-26a2-2b94-8c16560cd09d
> Delay estimator wrapper API changes. This should finalize the changes to delay estimator making it work for multi-probe.
>
> The changes are summarized here:
>
> delay_estimator.*
> -----------------
> Replaced assert() with correct error check. This is consistent with previous versions of the delay_estimator, i.e., to check for valid parameters where they are actually used and not high up in a wrapper layer.
>
> delay_estimator_internal.h
> --------------------------
> Pulled out the far-end part of DelayEstimator struct and put it in DelayEstimatorFarend. The only common parameter is spectrum_size, which we store in both and thereby avoiding having a Farend pointer in DelayEstimator.
>
> delay_estimator_wrapper.*
> -------------------------
> Added and updated descriptions. From Free(), Create(), Init() the far-end parts have been put in separate Farend versions. Same goes for the Process() which now has an AddFarSpectrum() version.
> The flow of calls should be something like (in pseudo-code)
>
> far* = CreateFarend(history_size)
> near* = Create(far, lookahead)
> InitFarend(far)
> Init(near)
> while call ongoing
> AddFarSpectrum(far, far_spectrum)
> Process(near, near_spectrum)
> end while
> Free(near)
> FreeFarend(far)
>
> delay_estimator_unittest.cc
> ---------------------------
> Added farend support setting up calls as mentioned above.
>
> aecm_core.*
> -----------
> Cleaned up some lint warnings.
> Added delay_estimator_farend pointer. Called Create(), Init() and Free() in above mentioned order.
> If AddFarSpectrumFix() was not successfully done, we end and return -1. This is what we would have done for Process().
>
> aec_core.*
> ----------
> Cleaned up some lint warnings.
> Added delay_estimator_farend pointer. Calls in proper order. Since we only use the delay estimator for logging there is no error handling. We only call Process() if AddFarSpectrum() was successful though.
>
> TEST=audioproc_unittest, trybots
> BUG=None
>
> Review URL: https://webrtc-codereview.appspot.com/1076006TBR=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1062008
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3429 4adac7df-926f-26a2-2b94-8c16560cd09d
The changes are summarized here:
delay_estimator.*
-----------------
Replaced assert() with correct error check. This is consistent with previous versions of the delay_estimator, i.e., to check for valid parameters where they are actually used and not high up in a wrapper layer.
delay_estimator_internal.h
--------------------------
Pulled out the far-end part of DelayEstimator struct and put it in DelayEstimatorFarend. The only common parameter is spectrum_size, which we store in both and thereby avoiding having a Farend pointer in DelayEstimator.
delay_estimator_wrapper.*
-------------------------
Added and updated descriptions. From Free(), Create(), Init() the far-end parts have been put in separate Farend versions. Same goes for the Process() which now has an AddFarSpectrum() version.
The flow of calls should be something like (in pseudo-code)
far* = CreateFarend(history_size)
near* = Create(far, lookahead)
InitFarend(far)
Init(near)
while call ongoing
AddFarSpectrum(far, far_spectrum)
Process(near, near_spectrum)
end while
Free(near)
FreeFarend(far)
delay_estimator_unittest.cc
---------------------------
Added farend support setting up calls as mentioned above.
aecm_core.*
-----------
Cleaned up some lint warnings.
Added delay_estimator_farend pointer. Called Create(), Init() and Free() in above mentioned order.
If AddFarSpectrumFix() was not successfully done, we end and return -1. This is what we would have done for Process().
aec_core.*
----------
Cleaned up some lint warnings.
Added delay_estimator_farend pointer. Calls in proper order. Since we only use the delay estimator for logging there is no error handling. We only call Process() if AddFarSpectrum() was successful though.
TEST=audioproc_unittest, trybots
BUG=None
Review URL: https://webrtc-codereview.appspot.com/1076006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3428 4adac7df-926f-26a2-2b94-8c16560cd09d
