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}
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
