Reason for revert:
This CL breaks internal dependencies.
Original issue's description:
> New statistics interface for APM
>
> This adds functions to enable and retrieve statistics from APM. These functions are not yet called, which will happen in a follow-up CL.
>
> BUG=webrtc:6525
>
> Committed: https://crrev.com/8b8d3e4c30e8ea3846b58dfd36d1fd35a7799df4
> Cr-Commit-Position: refs/heads/master@{#14810}
TBR=peah@webrtc.org,solenberg@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2456333002
Cr-Commit-Position: refs/heads/master@{#14814}
This adds functions to enable and retrieve statistics from APM. These functions are not yet called, which will happen in a follow-up CL.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2433153003
Cr-Commit-Position: refs/heads/master@{#14810}
the render side to the capture side using the same
pattern. Currently this is done independently for the
submodules.
This CL moves the the AEC functionality for this into
APM.
BUG=webrtc:5298, webrtc:6540
Review-Url: https://codereview.webrtc.org/2427553003
Cr-Commit-Position: refs/heads/master@{#14726}
AEC and AECM when these become full to also work when not
in debug mode.
BUG=webrtc:6530
Review-Url: https://codereview.webrtc.org/2419023002
Cr-Commit-Position: refs/heads/master@{#14637}
behavior of the audio processing module is quite complex and hard to
implement in a threadsafe and efficient manner. Therefore a new
scheme for setting the parameters in the audio processing module is
introduced in this CL.
The idea is to roll this scheme out gradually and as a first functionality
in the audio processing module where this is applied the level controller
was chosen. This CL includes the replacement of the Config-based
level controller scheme with the new scheme.
TBR=henrik.lundin@webrtc.org, solenberg@webrtc.org,
BUG=webrtc:5298
Review-Url: https://codereview.webrtc.org/2338493002
Cr-Commit-Position: refs/heads/master@{#14190}
Reason for revert:
Interface change in the mock breaks downstream code.
Original issue's description:
> The current scheme for setting parameters and specifying the behavior
> of the audio processing module is quite complex and hard to implement
> in a threadsafe and efficient manner. Therefore a new scheme for setting
> the parameters in the audio processing module is introduced in this CL.
>
> The idea is to roll this scheme out gradually and as a first functionality
> in the audio processing module where this is applied the level controller
> was chosen. This CL includes the replacement of the Config-based
> level controller scheme with the new scheme.
>
> BUG=webrtc:5298
>
> Committed: https://crrev.com/c8bbe3fe9aad9e9a1189a42dcaa8f5d6c261ecc8
> Cr-Commit-Position: refs/heads/master@{#14171}
TBR=solenberg@webrtc.org,henrik.lundin@webrtc.org,peah@webrtc.org
BUG=webrtc:5298
NOTRY=True
Review-Url: https://codereview.webrtc.org/2334583002
Cr-Commit-Position: refs/heads/master@{#14177}
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}
of the audio processing module is quite complex and hard to implement
in a threadsafe and efficient manner. Therefore a new scheme for setting
the parameters in the audio processing module is introduced in this CL.
The idea is to roll this scheme out gradually and as a first functionality
in the audio processing module where this is applied the level controller
was chosen. This CL includes the replacement of the Config-based
level controller scheme with the new scheme.
BUG=webrtc:5298
Review-Url: https://codereview.webrtc.org/2292863002
Cr-Commit-Position: refs/heads/master@{#14171}
processing module experiment description that was present
when AEC3 was not activated and when RefinedAdaptiveFilter
was activated.
BUG=webrtc:5778, webrtc:5777
Review URL: https://codereview.webrtc.org/1899123002
Cr-Commit-Position: refs/heads/master@{#12424}
The following algorithmic functionality was added:
-Add support for an exact regressor power to be computed
which avoids the issue with the updating of the filter
sometimes being unstable.
-Lowered the fixed step size of the adaptive filter to 0.05
which significantly reduces the sensitivity of the
adaptive filter to near-end noise, nonlinearities,
doubletalk and the unmodelled echo path tail. It also
reduces the tracking speed of the adaptive filter but the
chosen value proved to give a sufficient tradeoff for the
requirements on the adaptive filter.
To allow the new functionality to be selectively applied the following was done:
-A new Config was added for selectively activating the functionality.
-Functionality was added in the audioprocessing and echocancellationimpl classes
for passing the activation of the functionality down to the AEC algorithms.
To make the code for the introduction of the functionality clean,
the following refactoring was done:
-The selection of the step size was moved to a single place.
-The constant for the step size of the adaptive filter in extended filter mode was
made local.
-The state variable storing the step-size was renamed to a more describing name.
When the new functionality is not activated, the changes
have been tested for bitexactness on Linux.
TBR=minyue@webrtc.org
BUG=webrtc:5778, webrtc:5777
Review URL: https://codereview.webrtc.org/1887003002
Cr-Commit-Position: refs/heads/master@{#12384}
are active in the module and its submodules.
BUG=webrtc:5778, webrtc:5777
Review URL: https://codereview.webrtc.org/1886233003
Cr-Commit-Position: refs/heads/master@{#12371}
that can be called from the render side without making APM
singlethreaded.
This CL is addressing the problems with high render-side
call duration that were triggered by the CL
https://codereview.webrtc.org/1844583003
BUG=webrtc:5736
Review URL: https://codereview.webrtc.org/1859243002
Cr-Commit-Position: refs/heads/master@{#12266}
This CL removes the dependency of AudioProcessing in
EchoCancellerImpl. It is breaking the public APM API by
having a different error code behavior so please review it
carefully. I made a comment about the API breaking change
in the code section of this CL.
BUG=webrtc:5337
Review URL: https://codereview.webrtc.org/1770823002
Cr-Commit-Position: refs/heads/master@{#11998}
api function that directly returns aec_core.
BUG=webrtc:5201
Review URL: https://codereview.webrtc.org/1695743004
Cr-Commit-Position: refs/heads/master@{#11875}
that was not updated as it should.
The bug caused no negative impact at all apart
from a missed check that the Aec handles above
index 0 were not null. That check is, however,
done elsewhere so there was no negative impact
of this bug.
BUG=
Review URL: https://codereview.webrtc.org/1716203002
Cr-Commit-Position: refs/heads/master@{#11863}
In order for the change to be reviewable, the
move was made into two steps consisting of the
first two patches in this CL.
Step 1 (patch set 1):
-Changed file types to use .cc
-Changed buildfiles to use the new files
-Changed C code inclusion to properly match the changed
file formats (removed and added extern "C" declarations).
-Changed implicit void-> nonvoid casts that are
illegal in C++ to be explicit.
Step 2 (patch set 2):
-Changed all the warnings reported when uploading the CL.
-The warnings about formatting of the assembly optimized
code were not addressed though.
BUG=webrtc:5201
Review URL: https://codereview.webrtc.org/1713923002
Cr-Commit-Position: refs/heads/master@{#11727}
The general constraints on number of channels for AudioProcessing is:
num_in_channels == num_out_channels || num_out_channels == 1
When Beamforming is enabled and additional constraint was added forcing:
num_out_channels == 1
This artificial constraint was removed by adding upmixing support in CopyTo, since it was already supported for the AudioFrame interface using InterleaveTo.
Review URL: https://codereview.webrtc.org/1571013002
Cr-Commit-Position: refs/heads/master@{#11215}
* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in tests). Since channels will be changing to size_t, negative values will be illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks
All this was found in the course of constructing https://codereview.webrtc.org/1316523002/ , and is being landed separately first.
BUG=none
TEST=none
Review URL: https://codereview.webrtc.org/1534193008
Cr-Commit-Position: refs/heads/master@{#11191}
-Made the component error messages generic to be an unspecified error message.
BUG=webrtc:5099
Review URL: https://codereview.webrtc.org/1404743003
Cr-Commit-Position: refs/heads/master@{#10570}
The AEC dump was not self-contented enough in the sense that APM configuration is missing, and therefore, given an AEC dump, it is sometimes not clear how to reproduce problems.
This CL tries to address the problem.
Note that this cannot guarantee a perfect reproduction in all cases. Dumping from the middle of a call makes the initial states unknown and thus may make the result non-reproducible.
BUG=
TEST= 1. new dump in Chromium and unpack
2. unpack old dump
R=andrew@webrtc.org, peah@webrtc.org
Review URL: https://codereview.webrtc.org/1348903004 .
Cr-Commit-Position: refs/heads/master@{#10155}
We use this Config struct for enabling/disabling the delay agnostic
AEC. This change renames it to DelayAgnostic for readability reasons.
NOTE: The logic is reversed in this CL. The old ReportedDelay config
turned DA-AEC off, while the new DelayAgnostic turns it on.
The old Config is kept in parallel with the new during a transition
period. This is to avoid problems with API breakages. During this
period, ReportedDelay is disabled or DelayAgnostic is enabled, DA-AEC
is engaged in APM.
BUG=webrtc:4651
R=bjornv@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1211053006
Cr-Commit-Position: refs/heads/master@{#9531}
This is a follow-up to r9401, where the configuration DelayCorrection
was replaced by ExtendedFilter.
This change also removes the media constraint
kExperimentalEchoCancellation which was replaced by
kExtendedFilterEchoCancellation in the same CL.
Both settings that are now being removed were kept in the code to avoid
API breakages. In https://codereview.chromium.org/1167343004,
depending code has been updated to avoid breakages.
BUG=webrtc:4696
R=bjornv@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1181413004.
Cr-Commit-Position: refs/heads/master@{#9444}
(This reverts commit 3fbf3f8841b5460503fb646eaedcb063620434a8.)
The original submission was reverted because it broke the Chrome build. This is fixed in patch set 2 of this change by keeping the old MediaConstraintsInterface string kExperimentalEchoCancellation. It will be removed once the Chrome code has been updated.
Original description:
"We use this Config struct for enabling/disabling Extended filter mode in AEC. This change renames it to ExtendedFilter for readability reasons. The corresponding media constraint is also renamed to kExtendedFilterEchoCancellation.
The old Config is kept in parallel with the new during a transition period. This is to avoid problems with API breakages. During this period, if any of the two Configs are enabled, the extended filter mode is engaged in APM. That is, the two Configs are combined with an "OR" operation.
This change also renames experimental_aec in AudioOptions to extended_filter_aec."
BUG=webrtc:4696
R=bjornv@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1151573021.
Cr-Commit-Position: refs/heads/master@{#9401}
We use this Config struct for enabling/disabling Extended filter mode
in AEC. This change renames it to ExtendedFilter for readability
reasons. The corresponding media constraint is also renamed to
kExtendedFilterEchoCancellation.
The old Config is kept in parallel with the new during a transition
period. This is to avoid problems with API breakages. During this
period, if any of the two Configs are enabled, the extended filter
mode is engaged in APM. That is, the two Configs are combined with an
"OR" operation.
This change also renames experimental_aec in AudioOptions to extended_filter_aec.
BUG=4696
R=bjornv@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/54659004
Cr-Commit-Position: refs/heads/master@{#9378}
Now the ChannelBuffer has 2 separate arrays, one for the full-band data and one for the splitted one. The corresponding accessors are added to the ChannelBuffer.
This is done to avoid having to refresh the bands pointers in AudioBuffer. It will also allow us to have a general accessor like data()[band][channel][sample].
All the files using the ChannelBuffer needed to be re-factored.
Tested with modules_unittests, common_audio_unittests, audioproc, audioproc_f, voe_cmd_test.
R=andrew@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36999004
Cr-Commit-Position: refs/heads/master@{#8318}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8318 4adac7df-926f-26a2-2b94-8c16560cd09d
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
Doing something similar for the band 16-24kHz to what is done for the band 8-16kHz. The only difference is that there is no comfort noise added in this band. Could not test how this sounds because there are no aecdumps with 48kHz sample rate as nfar as I know.
Tested for 32kHz sample rate and the output is bitexact with how it was before this CL.
BUG=webrtc:3146
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/28319004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8080 4adac7df-926f-26a2-2b94-8c16560cd09d
