webrtc回音消除算法的delay值说明

android

1 webrtc定义了两种模式

Delay estimates for the two different supported modes.

These values are based on real-time round-trip delay estimates on a large set of devices and they are lower bounds since the filter length is 128 ms, so the AEC works for delays in the range [50, ~170] ms and [150, ~270] ms.

Note that, in most cases, the lowest delay estimate will not be utilized since devices that support low-latency output audio often supports HW AEC as well.

const int kLowLatencyModeDelayEstimateInMilliseconds = 50;

const int kHighLatencyModeDelayEstimateInMilliseconds = 150;

2 webrtc里面的使用

The delay estimate can take one of two fixed values depending on if the device supports low-latency output or not. 
However, it is also possible that the user explicitly selects the high-latency audio path, hence we use the selected |audio_layer| here to set the delay estimate.

delay_estimate_in_milliseconds_ =(audio_layer == AudioDeviceModule::kAndroidJavaAudio) ?kHighLatencyModeDelayEstimateInMilliseconds :kLowLatencyModeDelayEstimateInMilliseconds;

3 翻译

延时估计支持两种不同的模式。LowLatencyMode和kHighLatencyMode

这两种模式的值是基于在大量设备上的实时往返延迟估计；同时由于滤波器长度是128 ms，所以AEC的工作范围是(50 ~ 170)到(150 ~ 270)的区间，而这两种模式的值也刚好是这个区间的下限。

注意，在大多数情况下,低延迟估计不会被使用，因为设备支持低延迟输出音频通常利用支持硬件AEC。

依据设备是否支持低延迟输出，延迟估计可以选择两种固定的值中的一个。
但是，用户有可能显式地选择高延迟音频路径，因此我们根据所使用的参数| audio_layer |设置延时估计。

译者(我)注：如果用户选择高延迟的音频输出方式kAndroidJavaAudio，延迟估计值就是150，否则就是默认低延迟值50。

注意：国内小米 320ms

ios

ios 就固定60 =30+30
const UInt16 kFixedPlayoutDelayEstimate = 30;
const UInt16 kFixedRecordDelayEstimate = 30;

ios可以设置硬件延迟的/audiosession/VoiceProcessingIO

win/mac/linux通过计算获取