Implemented the 3 bands splitting filter bank by:
1. Upsample by 4/3.
2. Split twice into 2 bands.
3. Discard upper most band, because it is empty anyway.
A unittest was also implemented:
1. Generate a signal from presence or absence of sine waves of different frequencies.
2. Split into 3 bands and check their presence or absence.
3. Recombine the bands.
4. Calculate delay (as it is an IIR it depends on frequency).
5. Check that the cross correlation of input and output is high enough at that delay.
BUG=webrtc:3146
R=andrew@webrtc.org, bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31029004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7754 4adac7df-926f-26a2-2b94-8c16560cd09d
This doesn't change the behavior at all.
The logic behind this is having one class which manages all the splitting filters, because in the future we plan to add a 3 band one for 48kHz support.
It also breaks the dependency of the AudioBuffer with the filter states of these filters (which are going to be different for the 3 band one). The AudioBuffer is complicated enough and is going to need changes to support 3 bands in the future, so any simplification is a good idea.
On top of that it eliminates repeated code in the APM (now only iterating over channels, but then also deciding in how many bands to split). This should be managed by the AudioBuffer directly.
BUG=webrtc:3146
R=bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/32469004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7705 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
Break out the computation to a separate class, and call directly into
this from channel.cc rather than going through AudioProcessing. This
circumvents AudioProcessing's sample rate limitations.
We now compute the RMS over all samples rather than downmixing to a
single channel. This makes the call point in channel.cc easier, is
more "correct" and should have similar (negligible) complexity.
This caused slight changes in the RMS output, so the ApmTest.Process
reference has been updated. Snippet of the failing output:
[ RUN ] ApmTest.Process
Running test 4 of 12...
Value of: rms_level
Actual: 27
Expected: test->rms_level()
Which is: 28
Running test 5 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 6 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 10 of 12...
Value of: rms_level
Actual: 27
Expected: test->rms_level()
Which is: 28
Running test 11 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 12 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
BUG=3290
TESTED=Chrome assert is avoided and both voe_cmd_test and apprtc
produce reasonable printed out results from RMS().
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16459004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6056 4adac7df-926f-26a2-2b94-8c16560cd09d
Select "processing" rates based on the input and output sampling rates.
Resample the input streams to those rates, and if necessary to the
output rate.
- Remove deprecated stream format APIs.
- Remove deprecated device sample rate APIs.
- Add a ChannelBuffer class to help manage deinterleaved channels.
- Clean up the splitting filter state.
- Add a unit test which verifies the output against known-working
native format output.
BUG=2894
R=aluebs@webrtc.org, bjornv@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9919004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5959 4adac7df-926f-26a2-2b94-8c16560cd09d
This will allow an embedder to use it directly.
Adding inertia/hangover time between updates of the reported detection status to the algorithm, controlled by a parameter. That is usually desired and this way a consumer of
the class don't have to implement that. (VoiceEngine will let it be 1, which results in the same behavior as before, and keep controlling the hangover itself.)
R=andrew@webrtc.org, niklas.enbom@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6219004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5462 4adac7df-926f-26a2-2b94-8c16560cd09d
Instead have ProcessStream transparently handle changes to the stream
audio parameters (sample rate and channels). This removes two locks
per 10 ms ProcessStream call taken by VoiceEngine (four total with the
audio level indicator.)
Also, prepare future improvements by having the splitting filter take
a length parameter. This will allow it to work at different sample
rates. Remove the useless splitting_filter wrapper.
TESTED=voe_cmd_test with audio processing enabled and switching between
codecs; unit tests.
R=aluebs@webrtc.org, bjornv@webrtc.org, turaj@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/3949004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5346 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
* 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
