webrtc_m130/modules/audio_processing/aec3/erle_estimator_unittest.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

289 lines
12 KiB
C++
Raw Normal View History

/*
* Copyright (c) 2017 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#include "modules/audio_processing/aec3/erle_estimator.h"
#include <cmath>
#include "api/array_view.h"
#include "modules/audio_processing/aec3/render_delay_buffer.h"
#include "modules/audio_processing/aec3/spectrum_buffer.h"
#include "rtc_base/random.h"
#include "rtc_base/strings/string_builder.h"
#include "test/gtest.h"
namespace webrtc {
namespace {
constexpr int kLowFrequencyLimit = kFftLengthBy2 / 2;
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
constexpr float kTrueErle = 10.f;
constexpr float kTrueErleOnsets = 1.0f;
constexpr float kEchoPathGain = 3.f;
void VerifyErleBands(
rtc::ArrayView<const std::array<float, kFftLengthBy2Plus1>> erle,
float reference_lf,
float reference_hf) {
for (size_t ch = 0; ch < erle.size(); ++ch) {
std::for_each(
erle[ch].begin(), erle[ch].begin() + kLowFrequencyLimit,
[reference_lf](float a) { EXPECT_NEAR(reference_lf, a, 0.001); });
std::for_each(
erle[ch].begin() + kLowFrequencyLimit, erle[ch].end(),
[reference_hf](float a) { EXPECT_NEAR(reference_hf, a, 0.001); });
}
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
}
void VerifyErle(
rtc::ArrayView<const std::array<float, kFftLengthBy2Plus1>> erle,
float erle_time_domain,
float reference_lf,
float reference_hf) {
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
VerifyErleBands(erle, reference_lf, reference_hf);
EXPECT_NEAR(kTrueErle, erle_time_domain, 0.5);
}
void VerifyErleGreaterOrEqual(
rtc::ArrayView<const std::array<float, kFftLengthBy2Plus1>> erle1,
rtc::ArrayView<const std::array<float, kFftLengthBy2Plus1>> erle2) {
for (size_t ch = 0; ch < erle1.size(); ++ch) {
for (size_t i = 0; i < kFftLengthBy2Plus1; ++i) {
EXPECT_GE(erle1[ch][i], erle2[ch][i]);
}
}
}
void FormFarendTimeFrame(Block* x) {
const std::array<float, kBlockSize> frame = {
7459.88, 17209.6, 17383, 20768.9, 16816.7, 18386.3, 4492.83, 9675.85,
6665.52, 14808.6, 9342.3, 7483.28, 19261.7, 4145.98, 1622.18, 13475.2,
7166.32, 6856.61, 21937, 7263.14, 9569.07, 14919, 8413.32, 7551.89,
7848.65, 6011.27, 13080.6, 15865.2, 12656, 17459.6, 4263.93, 4503.03,
9311.79, 21095.8, 12657.9, 13906.6, 19267.2, 11338.1, 16828.9, 11501.6,
11405, 15031.4, 14541.6, 19765.5, 18346.3, 19350.2, 3157.47, 18095.8,
1743.68, 21328.2, 19727.5, 7295.16, 10332.4, 11055.5, 20107.4, 14708.4,
12416.2, 16434, 2454.69, 9840.8, 6867.23, 1615.75, 6059.9, 8394.19};
for (int band = 0; band < x->NumBands(); ++band) {
for (int channel = 0; channel < x->NumChannels(); ++channel) {
RTC_DCHECK_GE(kBlockSize, frame.size());
std::copy(frame.begin(), frame.end(), x->begin(band, channel));
Reland "Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3."" This is a reland of a66395e72f9fc86873bf443579ec73c3d78af240 Original change's description: > Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3." > > This is a reland of f3a197e55323aee974a932c52dd19fa88e5d4e38 > > Original change's description: > > Add core multi-channel pipeline in AEC3 > > This CL adds basic the basic pipeline to support multi-channel > > processing in AEC3. > > > > Apart from that, it removes the 8 kHz processing support in several > > places of the AEC3 code. > > > > Bug: webrtc:10913 > > Change-Id: If5b75fa325ed0071deea94a7546cb4a7adf22137 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150332 > > Commit-Queue: Per Åhgren <peah@webrtc.org> > > Reviewed-by: Sam Zackrisson <saza@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#29017} > > Bug: webrtc:10913 > Change-Id: Ifc4b13bd994cfd22dca8f8755fa5700617cc379d > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151124 > Reviewed-by: Sam Zackrisson <saza@webrtc.org> > Commit-Queue: Per Åhgren <peah@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#29034} Bug: webrtc:10913 Change-Id: Id8da5666df8c86f290c73ad5dc9958199f1a7ebe Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151127 Commit-Queue: Sam Zackrisson <saza@webrtc.org> Reviewed-by: Sam Zackrisson <saza@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29042}
2019-09-02 17:01:19 +02:00
}
}
}
void FormFarendFrame(const RenderBuffer& render_buffer,
float erle,
std::array<float, kFftLengthBy2Plus1>* X2,
rtc::ArrayView<std::array<float, kFftLengthBy2Plus1>> E2,
rtc::ArrayView<std::array<float, kFftLengthBy2Plus1>> Y2) {
const auto& spectrum_buffer = render_buffer.GetSpectrumBuffer();
const int num_render_channels = spectrum_buffer.buffer[0].size();
const int num_capture_channels = Y2.size();
X2->fill(0.f);
for (int ch = 0; ch < num_render_channels; ++ch) {
for (size_t k = 0; k < kFftLengthBy2Plus1; ++k) {
(*X2)[k] += spectrum_buffer.buffer[spectrum_buffer.write][ch][k] /
num_render_channels;
}
}
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
for (int ch = 0; ch < num_capture_channels; ++ch) {
std::transform(X2->begin(), X2->end(), Y2[ch].begin(),
[](float a) { return a * kEchoPathGain * kEchoPathGain; });
std::transform(Y2[ch].begin(), Y2[ch].end(), E2[ch].begin(),
[erle](float a) { return a / erle; });
}
}
void FormNearendFrame(
Block* x,
std::array<float, kFftLengthBy2Plus1>* X2,
rtc::ArrayView<std::array<float, kFftLengthBy2Plus1>> E2,
rtc::ArrayView<std::array<float, kFftLengthBy2Plus1>> Y2) {
for (int band = 0; band < x->NumBands(); ++band) {
for (int ch = 0; ch < x->NumChannels(); ++ch) {
std::fill(x->begin(band, ch), x->end(band, ch), 0.f);
Reland "Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3."" This is a reland of a66395e72f9fc86873bf443579ec73c3d78af240 Original change's description: > Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3." > > This is a reland of f3a197e55323aee974a932c52dd19fa88e5d4e38 > > Original change's description: > > Add core multi-channel pipeline in AEC3 > > This CL adds basic the basic pipeline to support multi-channel > > processing in AEC3. > > > > Apart from that, it removes the 8 kHz processing support in several > > places of the AEC3 code. > > > > Bug: webrtc:10913 > > Change-Id: If5b75fa325ed0071deea94a7546cb4a7adf22137 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150332 > > Commit-Queue: Per Åhgren <peah@webrtc.org> > > Reviewed-by: Sam Zackrisson <saza@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#29017} > > Bug: webrtc:10913 > Change-Id: Ifc4b13bd994cfd22dca8f8755fa5700617cc379d > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151124 > Reviewed-by: Sam Zackrisson <saza@webrtc.org> > Commit-Queue: Per Åhgren <peah@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#29034} Bug: webrtc:10913 Change-Id: Id8da5666df8c86f290c73ad5dc9958199f1a7ebe Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151127 Commit-Queue: Sam Zackrisson <saza@webrtc.org> Reviewed-by: Sam Zackrisson <saza@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29042}
2019-09-02 17:01:19 +02:00
}
}
X2->fill(0.f);
for (size_t ch = 0; ch < Y2.size(); ++ch) {
Y2[ch].fill(500.f * 1000.f * 1000.f);
E2[ch].fill(Y2[ch][0]);
}
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
}
void GetFilterFreq(
size_t delay_headroom_samples,
rtc::ArrayView<std::vector<std::array<float, kFftLengthBy2Plus1>>>
filter_frequency_response) {
const size_t delay_headroom_blocks = delay_headroom_samples / kBlockSize;
for (size_t ch = 0; ch < filter_frequency_response[0].size(); ++ch) {
for (auto& block_freq_resp : filter_frequency_response) {
block_freq_resp[ch].fill(0.f);
}
for (size_t k = 0; k < kFftLengthBy2Plus1; ++k) {
filter_frequency_response[delay_headroom_blocks][ch][k] = kEchoPathGain;
}
}
}
} // namespace
class ErleEstimatorMultiChannel
: public ::testing::Test,
public ::testing::WithParamInterface<std::tuple<size_t, size_t>> {};
INSTANTIATE_TEST_SUITE_P(MultiChannel,
ErleEstimatorMultiChannel,
::testing::Combine(::testing::Values(1, 2, 4, 8),
::testing::Values(1, 2, 8)));
TEST_P(ErleEstimatorMultiChannel, VerifyErleIncreaseAndHold) {
const size_t num_render_channels = std::get<0>(GetParam());
const size_t num_capture_channels = std::get<1>(GetParam());
Reland "Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3."" This is a reland of a66395e72f9fc86873bf443579ec73c3d78af240 Original change's description: > Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3." > > This is a reland of f3a197e55323aee974a932c52dd19fa88e5d4e38 > > Original change's description: > > Add core multi-channel pipeline in AEC3 > > This CL adds basic the basic pipeline to support multi-channel > > processing in AEC3. > > > > Apart from that, it removes the 8 kHz processing support in several > > places of the AEC3 code. > > > > Bug: webrtc:10913 > > Change-Id: If5b75fa325ed0071deea94a7546cb4a7adf22137 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150332 > > Commit-Queue: Per Åhgren <peah@webrtc.org> > > Reviewed-by: Sam Zackrisson <saza@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#29017} > > Bug: webrtc:10913 > Change-Id: Ifc4b13bd994cfd22dca8f8755fa5700617cc379d > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151124 > Reviewed-by: Sam Zackrisson <saza@webrtc.org> > Commit-Queue: Per Åhgren <peah@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#29034} Bug: webrtc:10913 Change-Id: Id8da5666df8c86f290c73ad5dc9958199f1a7ebe Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151127 Commit-Queue: Sam Zackrisson <saza@webrtc.org> Reviewed-by: Sam Zackrisson <saza@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29042}
2019-09-02 17:01:19 +02:00
constexpr int kSampleRateHz = 48000;
constexpr size_t kNumBands = NumBandsForRate(kSampleRateHz);
std::array<float, kFftLengthBy2Plus1> X2;
std::vector<std::array<float, kFftLengthBy2Plus1>> E2(num_capture_channels);
std::vector<std::array<float, kFftLengthBy2Plus1>> Y2(num_capture_channels);
std::vector<bool> converged_filters(num_capture_channels, true);
EchoCanceller3Config config;
config.erle.onset_detection = true;
Block x(kNumBands, num_render_channels);
std::vector<std::vector<std::array<float, kFftLengthBy2Plus1>>>
filter_frequency_response(
config.filter.refined.length_blocks,
std::vector<std::array<float, kFftLengthBy2Plus1>>(
num_capture_channels));
std::unique_ptr<RenderDelayBuffer> render_delay_buffer(
RenderDelayBuffer::Create(config, kSampleRateHz, num_render_channels));
GetFilterFreq(config.delay.delay_headroom_samples, filter_frequency_response);
ErleEstimator estimator(0, config, num_capture_channels);
FormFarendTimeFrame(&x);
render_delay_buffer->Insert(x);
render_delay_buffer->PrepareCaptureProcessing();
// Verifies that the ERLE estimate is properly increased to higher values.
FormFarendFrame(*render_delay_buffer->GetRenderBuffer(), kTrueErle, &X2, E2,
Y2);
for (size_t k = 0; k < 1000; ++k) {
render_delay_buffer->Insert(x);
render_delay_buffer->PrepareCaptureProcessing();
estimator.Update(*render_delay_buffer->GetRenderBuffer(),
filter_frequency_response, X2, Y2, E2, converged_filters);
}
VerifyErle(estimator.Erle(/*onset_compensated=*/true),
std::pow(2.f, estimator.FullbandErleLog2()), config.erle.max_l,
config.erle.max_h);
VerifyErleGreaterOrEqual(estimator.Erle(/*onset_compensated=*/false),
estimator.Erle(/*onset_compensated=*/true));
VerifyErleGreaterOrEqual(estimator.ErleUnbounded(),
estimator.Erle(/*onset_compensated=*/false));
FormNearendFrame(&x, &X2, E2, Y2);
// Verifies that the ERLE is not immediately decreased during nearend
// activity.
for (size_t k = 0; k < 50; ++k) {
render_delay_buffer->Insert(x);
render_delay_buffer->PrepareCaptureProcessing();
estimator.Update(*render_delay_buffer->GetRenderBuffer(),
filter_frequency_response, X2, Y2, E2, converged_filters);
}
VerifyErle(estimator.Erle(/*onset_compensated=*/true),
std::pow(2.f, estimator.FullbandErleLog2()), config.erle.max_l,
config.erle.max_h);
VerifyErleGreaterOrEqual(estimator.Erle(/*onset_compensated=*/false),
estimator.Erle(/*onset_compensated=*/true));
VerifyErleGreaterOrEqual(estimator.ErleUnbounded(),
estimator.Erle(/*onset_compensated=*/false));
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
}
TEST_P(ErleEstimatorMultiChannel, VerifyErleTrackingOnOnsets) {
const size_t num_render_channels = std::get<0>(GetParam());
const size_t num_capture_channels = std::get<1>(GetParam());
Reland "Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3."" This is a reland of a66395e72f9fc86873bf443579ec73c3d78af240 Original change's description: > Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3." > > This is a reland of f3a197e55323aee974a932c52dd19fa88e5d4e38 > > Original change's description: > > Add core multi-channel pipeline in AEC3 > > This CL adds basic the basic pipeline to support multi-channel > > processing in AEC3. > > > > Apart from that, it removes the 8 kHz processing support in several > > places of the AEC3 code. > > > > Bug: webrtc:10913 > > Change-Id: If5b75fa325ed0071deea94a7546cb4a7adf22137 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150332 > > Commit-Queue: Per Åhgren <peah@webrtc.org> > > Reviewed-by: Sam Zackrisson <saza@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#29017} > > Bug: webrtc:10913 > Change-Id: Ifc4b13bd994cfd22dca8f8755fa5700617cc379d > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151124 > Reviewed-by: Sam Zackrisson <saza@webrtc.org> > Commit-Queue: Per Åhgren <peah@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#29034} Bug: webrtc:10913 Change-Id: Id8da5666df8c86f290c73ad5dc9958199f1a7ebe Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151127 Commit-Queue: Sam Zackrisson <saza@webrtc.org> Reviewed-by: Sam Zackrisson <saza@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29042}
2019-09-02 17:01:19 +02:00
constexpr int kSampleRateHz = 48000;
constexpr size_t kNumBands = NumBandsForRate(kSampleRateHz);
std::array<float, kFftLengthBy2Plus1> X2;
std::vector<std::array<float, kFftLengthBy2Plus1>> E2(num_capture_channels);
std::vector<std::array<float, kFftLengthBy2Plus1>> Y2(num_capture_channels);
std::vector<bool> converged_filters(num_capture_channels, true);
EchoCanceller3Config config;
config.erle.onset_detection = true;
Block x(kNumBands, num_render_channels);
std::vector<std::vector<std::array<float, kFftLengthBy2Plus1>>>
filter_frequency_response(
config.filter.refined.length_blocks,
std::vector<std::array<float, kFftLengthBy2Plus1>>(
num_capture_channels));
std::unique_ptr<RenderDelayBuffer> render_delay_buffer(
RenderDelayBuffer::Create(config, kSampleRateHz, num_render_channels));
GetFilterFreq(config.delay.delay_headroom_samples, filter_frequency_response);
ErleEstimator estimator(/*startup_phase_length_blocks=*/0, config,
num_capture_channels);
FormFarendTimeFrame(&x);
render_delay_buffer->Insert(x);
render_delay_buffer->PrepareCaptureProcessing();
for (size_t burst = 0; burst < 20; ++burst) {
FormFarendFrame(*render_delay_buffer->GetRenderBuffer(), kTrueErleOnsets,
&X2, E2, Y2);
for (size_t k = 0; k < 10; ++k) {
render_delay_buffer->Insert(x);
render_delay_buffer->PrepareCaptureProcessing();
estimator.Update(*render_delay_buffer->GetRenderBuffer(),
filter_frequency_response, X2, Y2, E2,
converged_filters);
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
}
FormFarendFrame(*render_delay_buffer->GetRenderBuffer(), kTrueErle, &X2, E2,
Y2);
for (size_t k = 0; k < 1000; ++k) {
render_delay_buffer->Insert(x);
render_delay_buffer->PrepareCaptureProcessing();
estimator.Update(*render_delay_buffer->GetRenderBuffer(),
filter_frequency_response, X2, Y2, E2,
converged_filters);
}
FormNearendFrame(&x, &X2, E2, Y2);
for (size_t k = 0; k < 300; ++k) {
render_delay_buffer->Insert(x);
render_delay_buffer->PrepareCaptureProcessing();
estimator.Update(*render_delay_buffer->GetRenderBuffer(),
filter_frequency_response, X2, Y2, E2,
converged_filters);
}
}
VerifyErleBands(estimator.ErleDuringOnsets(), config.erle.min,
config.erle.min);
FormNearendFrame(&x, &X2, E2, Y2);
for (size_t k = 0; k < 1000; k++) {
estimator.Update(*render_delay_buffer->GetRenderBuffer(),
filter_frequency_response, X2, Y2, E2, converged_filters);
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
}
// Verifies that during ne activity, Erle converges to the Erle for
// onsets.
VerifyErle(estimator.Erle(/*onset_compensated=*/true),
std::pow(2.f, estimator.FullbandErleLog2()), config.erle.min,
config.erle.min);
}
Improves in the ERLE estimation for AEC3 The estimation on how well the linear filter in the AEC3 is performing is done through an estimation of the ERLE. That estimation is then used for knowing how much the suppressor needs to react in order to cancel all the echoes. In the current code, the ERLE is quite conservative during farend inactivity and it is common that it goes to a minimum value during those periods. Under highly varying conditions, that is probably the right approach. However, in other scenarios where conditions does not change that fast there is a loss in transparency that could be avoided by means of a different ERLE estimation. In the current CL, the ERLE estimation has been changed in the following way: - During farend activity the ERLE is estimated through a 1st order AR smoother. This smoother goes faster toward lower ERLE values than to larger ones in order to avoid overestimation of this value. Furthermore, during the beginning of the farend burst, an estimation of the ERLE is done that aim to represent the performance of the linear filter during onsets. Under highly variant environments, those quantities, the ERLE during onsets and the one computed during the whole farend duration, would differ a lot. If the environment is more stationary, those quantities would be much more similar. - During nearend activity the ERLE estimation is decreased toward a value of the ERLE during onsets. Bug: webrtc:9040 Change-Id: Ieab86370a4333d2d0cd7041047d29651de4f6827 Reviewed-on: https://webrtc-review.googlesource.com/62342 Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22568}
2018-03-22 14:53:23 +01:00
} // namespace webrtc