On non-Android the delay estimator in audio_processing/aec has solely been used for logging purposes. The maximum possible observed delay has been 236 ms. We have seen longer delays for which the delay estimate at best ends up at 236 ms, but can also be 'random'. reported delays are clamped to 500 ms.
This cl extends the delay estimation window to match that.
BUG=4086, 3504, 4113
TESTED=locally on Linux and trybots
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36569004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7989 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
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
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
During porting some neon optimizations to sse2 the ApmTest.Process failed despite bit exact outputs. The reason is that with float data between component, as to previously truncating to int, we get small deviations in logged metrics. This affected a noise probability to a small fraction, which is not a particular bug.
This CL change the comparison from EXPECT_EQ() to EXPECT_NEAR() which then as a result makes the test run on Mac and Windows as well.
For int values a deviation of 1 is acceptable, which would include any rounding errors.
For float values a deviation of 0.0005 is chosen by looking at current test stats for the affected platforms/optimizations.
BUG=114
TESTED=locally on linux with and without sse2 optimizations and trybots
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20289004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7149 4adac7df-926f-26a2-2b94-8c16560cd09d
- Disables ApmTest.EchoCancellationReportsCorrectDelays
This test relys completely on the structure of how reported system delays are handled in AEC. In addition it assumes a fix setup of delay logging buffers. This test should be refactored.
- Adds flag to turn off reported_delay in audioproc
Now it is feasible to turn on and off the use of reported system delays.
BUG=N/A
R=aluebs@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16749004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6492 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
The behavior differ between "normal" and "extended" modes when using AEC. In the extended filter mode nothing is processed until we have received a farend frame. This is exactly what is needed in this part of the splitting filter test.
On Android, we do not use the normal mode, which made the test to fail.
BUG=3445
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12679004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6368 4adac7df-926f-26a2-2b94-8c16560cd09d
We want to remove energy_ entirely as we've seen that carrying around
this potentially invalid value is dangerous.
Results in the removal of AudioBuffer::is_muted(). This wasn't used in
practice any longer, after the level calculation moved directly to
channel.cc
Instead, now use ProcessMuted() in channel.cc, to shortcut the level
computation when the signal is muted.
BUG=3315
TESTED=Muting the channel in voe_cmd_test results in rms=127.
R=bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6159 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
- Add an Initialize() overload to allow specification of format
parameters. This is mainly useful for testing, but could be used in
the cases where a consumer knows the format before the streams arrive.
- Add a reverse_sample_rate_hz_ parameter to prepare for mismatched
capture and render rates. There is no functional change as it is
currently constrained to match the capture rate.
- Fix a bug in the float dump: we need to use add_ rather than set_.
- Add a debug dump test for both int and float interfaces.
- Enable unpacking of float dumps.
- Enable audioproc to read float dumps.
- Move more shared functionality to test_utils.h, and generally tidy up
a bit by consolidating repeated code.
BUG=2894
TESTED=Verified that the output produced by the float debug dump test is
correct. Processed the resulting debug dump file with audioproc and
ensured that we get identical output. (This is crucial, as we need to
be able to exactly reproduce online results offline.)
R=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9489004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5676 4adac7df-926f-26a2-2b94-8c16560cd09d
This is mainly to support the native audio format in Chrome. Although
this implementation just moves the float->int conversion under the hood,
we will transition AudioProcessing towards supporting this format
throughout.
- Add a test which verifies we get identical output with the float and
int interfaces.
- The float and int wrappers are tasked with conversion to the
AudioBuffer format. A new shared Process/Analyze method does most of
the work.
- Add a new field to the debug.proto to hold deinterleaved data.
- Add helpers to audio_utils.cc, and start using numeric_limits.
- Note that there was no performance difference between numeric_limits
and a literal value when measured on Linux using gcc or clang.
BUG=2894
R=aluebs@webrtc.org, bjornv@webrtc.org, henrikg@webrtc.org, tommi@webrtc.org, turaj@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9179004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5641 4adac7df-926f-26a2-2b94-8c16560cd09d
Voice engine shouldn't really have to manage this. Instead, have AGC
keep track of the last input volume, so that it can avoid getting stuck
under coarsely quantized conditions.
Add a test to verify the behavior.
TESTED=unittests, and observed that AGC didn't get stuck on a MacBook
where this problem can actually occur.
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8729004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5571 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
