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}
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}
Support for reading the newly added fields will be added in a another CL.
BUG=webrtc:5759, webrtc:5724
Review URL: https://codereview.webrtc.org/1878533002
Cr-Commit-Position: refs/heads/master@{#12316}
rate that is higher than the specified rate, and not
the closest native rate the need for a name change has been
raised. This CL addresses that.
BUG=webrtc:5298
Review URL: https://codereview.webrtc.org/1863023002
Cr-Commit-Position: refs/heads/master@{#12302}
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}
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}
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}
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}
The 3-band splitting filter is highly complex on this architecture. Today this is not a problem, because on those platforms we mostly use AECM which forces us to downsample to 16kHz anyway, but this is a way of guarding against it. In the long term we want to optimize the 3-band splitting filter for ARM architectures, but for now we can just disable it.
Review URL: https://codereview.webrtc.org/1766103002
Cr-Commit-Position: refs/heads/master@{#11900}
Sparse macro replaced for all audio histograms that have a constant name.
BUG=webrtc:5283
Review URL: https://codereview.webrtc.org/1762863003
Cr-Commit-Position: refs/heads/master@{#11885}
api function that directly returns aec_core.
BUG=webrtc:5201
Review URL: https://codereview.webrtc.org/1695743004
Cr-Commit-Position: refs/heads/master@{#11875}
(This is a re-land---without the real_fourier.h changes---of 11716, which was reverted in 11726.)
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1731153002
Cr-Commit-Position: refs/heads/master@{#11742}
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}
Reason for revert:
Breaks downstream compilation using webrtc/common_audio/real_fourier.h. Let's chat tomorrow on how to coordinate a re-land.
Original issue's description:
> Replace scoped_ptr with unique_ptr in webrtc/common_audio/
>
> BUG=webrtc:5520
>
> Committed: https://crrev.com/79d7a499c0c3e1de8f5ad1138236f0386701053f
> Cr-Commit-Position: refs/heads/master@{#11716}
TBR=henrik.lundin@webrtc.org,kwiberg@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1726043002
Cr-Commit-Position: refs/heads/master@{#11726}
Apart from being motivated in order to make the source files shorter
this is needed when separating the APM submodules structs into
separate files.
BUG=
Review URL: https://codereview.webrtc.org/1678813002
Cr-Commit-Position: refs/heads/master@{#11611}
This will make it align with protoc tools that use the relative
path from the project root to the files in the output path.
Having this, no hacks will need to be applied downstream.
TBR=henrik.lundin@webrtc.org
NOTRY=True
Review URL: https://codereview.webrtc.org/1673263002
Cr-Commit-Position: refs/heads/master@{#11540}
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}
This implementation will be replaced by a faster one and sparse will be removed.
BUG=webrtc:5283
Review URL: https://codereview.webrtc.org/1530913002
Cr-Commit-Position: refs/heads/master@{#11099}
Reason for revert:
Compile error on Android needs to be fixed before relanding.
Original issue's description:
> Reland "Added option to specify a maximum file size when recording an AEC dump.", commit ae2c5ad12afc8cc29fe9c59dea432b697b871a87.
>
> The revert of the original CL was commit 36d4c545007129446e551c45c17b25377dce89a4.
> Original review: https://codereview.webrtc.org/1413483003/
>
> The original CL changes a function on audio_processing.h that is used by Chrome, this CL adds back the old function.
>
> NOTRY=true
> TBR=glaznev@webrtc.org, henrik.lundin@webrtc.org, solenberg@google.com, henrikg@webrtc.org, perkj@webrtc.org
> BUG=webrtc:4741
>
> Committed: https://crrev.com/f4f5cb09277d5ef6aeac8341e5f54a055867803a
> Cr-Commit-Position: refs/heads/master@{#11093}
TBR=glaznev@webrtc.org,henrik.lundin@webrtc.org,solenberg@google.com,henrikg@webrtc.org,perkj@webrtc.org,kwiberg@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4741
Review URL: https://codereview.webrtc.org/1537213002
Cr-Commit-Position: refs/heads/master@{#11094}
Reason for revert:
Breaks Chrome-FYI bots because of a change in the StartDebugRecording function in audio_processing.h, that is called from Chrome.
Original issue's description:
> Added option to specify a maximum file size when recording an AEC dump.
>
> For applications with a strict filesize limit for debug files,
> I added an option to specify a maximum filesize for AEC dumps. An
> existing unit test is extended to check that the feature works as
> advertised.
>
> BUG=webrtc:4741
> TBR=glaznev@webrtc.org
>
> Committed: https://crrev.com/ae2c5ad12afc8cc29fe9c59dea432b697b871a87
> Cr-Commit-Position: refs/heads/master@{#11081}
TBR=pthatcher@webrtc.org,henrik.lundin@webrtc.org,henrikg@webrtc.org,solenberg@webrtc.org,andrew@webrtc.org,kwiberg@webrtc.org,perkj@webrtc.org,glaznev@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4741
Review URL: https://codereview.webrtc.org/1533913004
Cr-Commit-Position: refs/heads/master@{#11087}
For applications with a strict filesize limit for debug files,
I added an option to specify a maximum filesize for AEC dumps. An
existing unit test is extended to check that the feature works as
advertised.
BUG=webrtc:4741
TBR=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1413483003
Cr-Commit-Position: refs/heads/master@{#11081}
using the wrong sample rate for the render signal.
The CL is basically a partial revert of the related changes done on
output_mixer.cc in the CL https://codereview.webrtc.org/1234463003.
The CL also reverts the removal of the input_sample_rate_hz() method
that was removed as part of the CL
https://codereview.webrtc.org/1379123002 (as it was at that point
no longer used).
It should be noted that this CL turns off the effect of the
IntelligibilityEnhancer when the AudioFrame AudioProcessing APIs are
used. While it may be possible to solve that by adding upsampling after
the API call, that approach was discarded due to that:
-That would add extra processing in the echo path, leading to possible
AEC performance reduction.
-That would add extra complexity for the mobile case.
-That would only patch the intelligibility enhancer operation as the
proper way to do such an operation is within APM.
-The intelligibility enhancer is not active by default anywhere.
BUG=webrtc:5237
Review URL: https://codereview.webrtc.org/1525173002
Cr-Commit-Position: refs/heads/master@{#11045}
