Move the resources to //resources and upload them to Google Storage.
BUG=webrtc:6727
Review-Url: https://codereview.webrtc.org/2508943004
Cr-Commit-Position: refs/heads/master@{#15152}
internal block size of the AEC differ from the frame
size in the AEC output.
Before this CL, this buffering was done using ringbuffers
as well as secondary internal AEC buffers that were stored
on the state. The internal buffers were redundant, and the
ringbuffers were so short that the benefit of using
ringbuffers were lost.
This CL addresses the above issues by replacing the
ringbuffers by linear buffers. This has the main advantage
of cleaner code but it should significantly less
computational complex.
Furthermore, as the complexity of the function where the
conversion to external and internal AEC frame sizes is done
increased significantly with the changes in this CL, the
CL also include refactoring the near-end buffer handling
to increase readability and reduce code repetition.
After the changes in this CL it is very clear that the
former buffering of the output was incorrectly done for
the first frames. This CL corrects that but in doing that
it breaks the bitexactness with the former code.
The bitexactness is, however, only broken for the first
1000 samples and it has been verified that for a test suite
the CL maintains bitexactness in the AEC output
after the first 1000 samples.
This CL is chained to the CL https://codereview.webrtc.org/2311833002/ and will be
followed by more CLs that refactor the other buffers
inside the AEC.
BUG=webrtc:5298, webrtc:6018
Review-Url: https://codereview.webrtc.org/2321483002
Cr-Commit-Position: refs/heads/master@{#14184}
functionalities doing sample-rate conversions:
-The implicit resampling done in the AudioBuffer CopyTo,
CopyFrom, InterleaveTo and DeinterleaveFrom methods.
-The multi-band splitting scheme.
The selection of rates in these have been difficult and
complicated, partly due to that the APM API which allows
for activating the APM submodules without notifying
the APM.
This CL adds functionality that for each capture frame
polls all submodules for whether they are active or not
and compares this against a cached result.
Furthermore, new functionality is added that based on the
results of the comparison do a reinitialization of the APM.
This has several advantages
-The code deciding on whether to analysis and synthesis is
needed for the bandsplitting can be much simplified and
centralized.
-The selection of the processing rate can be done such as
to avoid the implicit resampling that was in some cases
unnecessarily done.
-The optimization for whether an output copy is needed
that was done to improve performance due to the implicit
resampling is no longer needed, which simplifies the
code and makes it less error-prone in the sense that
is no longer neccessary to keep track of whether any
module has changed the signal.
Finally, it should be noted that the polling of the state
for all the submodules was done previously as well, but in
a less obvious and distributed manner.
BUG=webrtc:6181, webrtc:6220, webrtc:5298, webrtc:6296, webrtc:6298, webrtc:6297
Review-Url: https://codereview.webrtc.org/2304123002
Cr-Commit-Position: refs/heads/master@{#14175}
There were a series of changes in the calculation of echo metrics. There changes made the existing unittests lose, e.g., EXPECT_EQ become EXPECT_NEAR. It is good time to protect the echo calculation more strictly.
The change is not simply generating a new reference file and change EXPECT_NEAR to EXPECT_EQ. It strengthens the test as well. Main changes are
1. the old test only sample a metric at the end of processing, while the new test takes metrics during the call with a certain time interval. This gives a much stronger protection.
2. added protection of a newly added metric, called divergent_filter_fraction.
3. as said, use EXPECT_EQ (actually ASSERT_EQ) instead of EXPECT_NEAR as much as possible, even for float point values. This may be too restrictive. But it can be good to be restrictive at the beginning.
BUG=
Review-Url: https://codereview.webrtc.org/1969403003
Cr-Commit-Position: refs/heads/master@{#12871}
Added conditional updating of the statistics and the delay estimate so that
updates are only done when the farend is non-stationary.
The reason for this is that all the values that go into the updating of the
statistics, and that in turn are also used to update the delay, are frozen
when the farend signal is non-stationary. Therefore, when the farend signal
is silent (stationary), the last estimates present before the silent (stationary)
period began are used to continue to update the statistics. This is a problem as
the updating is done in a manner that assumes that the estimates continue
to be updated.
This CL conditions the updating based on stationarity instead of silence
as both are treated in the same manner in the delay agnostic AEC.
This makes sense theoretically as the delay agnostic AEC operates on
analyzing power deviations (in bands) from a slowly updated average power and
therefore for a stationary signal will have no such deviations to base its analysis
on.
BUG=webrtc:5875, chromium:576624
NOTRY=True
Review-Url: https://codereview.webrtc.org/1967033002
Cr-Commit-Position: refs/heads/master@{#12700}
The first approach landed here: https://codereview.webrtc.org/1773173002
But it was partially reverted, because it affected the AEC performance, here: https://codereview.webrtc.org/1867483003/
The main difference of this approach is that it doesn't use the 3-band splitting filter in the reverse stream, which seems to be the culprit of the AEC regression.
Also, the 2-band splitting filter has been used for the 32kHz case for a long time without any problem, and this is expanded in the CL to cover the 48kHz case as well.
BUG=webrtc:5725
TBR=tina.legrand@webrtc.org
Review URL: https://codereview.webrtc.org/1865633005
Cr-Commit-Position: refs/heads/master@{#12451}
were added in https://codereview.webrtc.org/1773173002.
The reason for the revert is that for some scenarios
that CL causes problems in the coherence estimate used
in the AEC, which in turn causes echo leakage.
The reason for not reverting the actual CL is that
it would cause subsequent CLs to be reverted as well.
Therefore the choice was made to in this CK
instead revert the effects of that CL.
With the changes in this CL, the behavior is bitexact
to what it was before the CL mentioned above.
TBR=aluebs@webrtc.org
BUG=webrtc:5725
Review URL: https://codereview.webrtc.org/1867483003
Cr-Commit-Position: refs/heads/master@{#12259}
Reason for revert:
Breaks Android it looks like.
See your own try jobs and
https://build.chromium.org/p/client.webrtc/builders/Android32%20Tests%20%28L%...
Original issue's description:
> Drop the 16kHz sample rate restriction on AECM and zero out higher bands
>
> The restriction has been removed completely and AECM now supports any
> number of higher bands. But this has been achieved by always zeroing out the
> higher bands, instead of applying a constant gain which is the average over half
> of the lower band (like it is done for the AEC), because that would be
> non-trivial to implement and we don't want to spend too much time on AECM, since
> we want to get rid of it in the long term anyway.
>
> R=peah@webrtc.org, solenberg@webrtc.org, tina.legrand@webrtc.org
>
> Committed: https://crrev.com/f687d53aabee0523ce6e9e0636163af8df120e41
> Cr-Commit-Position: refs/heads/master@{#11931}
TBR=peah@webrtc.org,turaj@webrtc.org,tina.legrand@webrtc.org,solenberg@webrtc.org,aluebs@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1781893002
Cr-Commit-Position: refs/heads/master@{#11932}
The restriction has been removed completely and AECM now supports any
number of higher bands. But this has been achieved by always zeroing out the
higher bands, instead of applying a constant gain which is the average over half
of the lower band (like it is done for the AEC), because that would be
non-trivial to implement and we don't want to spend too much time on AECM, since
we want to get rid of it in the long term anyway.
R=peah@webrtc.org, solenberg@webrtc.org, tina.legrand@webrtc.org
Review URL: https://codereview.webrtc.org/1774553002 .
Cr-Commit-Position: refs/heads/master@{#11931}
Because of the Finch experiment, this will not affect Chrome's behaviour at all.
The SNRs in AudioProcessingTest.Formats were only increased to the next multiple of 5.
BUG=webrtc:3146
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43359004
Cr-Commit-Position: refs/heads/master@{#9263}
To more easily determine if for example the AEC is not working properly one could monitor how often the estimated delay is out of bounds. With out of bounds we mean either being negative or too large, where both cases will break the AEC.
A new delay metric is added telling the user how often poor delay values were estimated. This is measured in percentage since last time the metrics were calculated.
All APIs have been updated with a third parameter with EchoCancellation::GetDelayMetrics() giving the option to exclude the new metric not to break existing code.
The new metric has been added to audio_processing_unittests with an additional protobuf member, and reference files accordingly updated.
voe_auto_test has not been updated to display the new metric.
BUG=4246
TESTED=audioproc on files
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39739004
Cr-Commit-Position: refs/heads/master@{#8230}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8230 4adac7df-926f-26a2-2b94-8c16560cd09d
The average speech probability for the higher band is multiplied by the quotient of the process and analyze powers, to avoid thinking that suppressed echo is speech. In order to do this both magnitudes, alanyze and process, needed to be stored. This also was used to calculate different previous STSA estimates for analyze and process.
This CL was tested on two long team member recordings (bjornv and kwiberg) and the noisiest (5) recordings from the QA set.
BUG=webrtc:3763
R=andrew@webrtc.org, bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23799004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7437 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
In r6591 a shift macro was removed affecting AECM. In addition to that change a bug was fixed. The fix added a few voice_counts in ApmTest.Process.
This CL updates the reference file, even though it is not used in practice since the test is currently turned off for Android (where AECM is used).
BUG=3672
TESTED=locally
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14089004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6868 4adac7df-926f-26a2-2b94-8c16560cd09d
Internally, it already worked on floats. This patch just changes the
signature of a bunch of functions so that floats can be passed
directly from the new and improved AudioBuffer without converting the
data to int and back again first.
(The reference data to the ApmTest.Process test had to be modified
slightly; this is because the noise suppressor comes immediately after
the echo canceller, which also works on floats. If I truncate to
integers between the two steps, ApmTest.Process doesn't complain, but
of course that's exactly the sort of thing the float conversion is
supposed to let us avoid...)
BUG=
R=aluebs@webrtc.org, bjornv@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/13519004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6385 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
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
