webrtc 的回声抵消(aec、aecm)算法简介

  webrtc 的回声抵消(aec、aecm)算法主要包括以下几个重要模块:1.回声时延估计 2.NLMS(归一化最小均方自适应算法) 3.NLP(非线性滤波) 4.CNG(舒适噪声产生),一般经典aec算法还应包括双端检测(DT)。考虑到webrtc使用的NLMS、NLP和CNG都属于经典算法范畴,故只做简略介绍,本文重点介绍webrtc的回声时延估计算法,这也是webrtc回声抵消算法区别一般算法(如视频会议中的算法)比较有特色的地方。

1) 回声时延估计
     回声延时长短对回声抵消器的性能有比较大的影响(此处不考虑pc上的线程同步的问题),过长的滤波器抽头也无法实际应用,因此时延估计算法就显得比较重要了。常用且容易想到的估计算法是基于相关的时延估计算法(学过通信原理的应该不会陌生),另外相关算法在语音编码中也得到广泛的应用,如 amr系列,G.729系列 ,G.718等编码器。在语音信号自相关求基音周期时,由于编码器一般按帧处理,帧长度一般是10或20ms,在该时延范围内搜索基音周期运算量较小,然而对于回声抵消的应用场合,延时搜索范围比较大,带来很高的运算复杂度。在手持终端设备上,我们需要考虑移动环境的变化对算法性能的影响,比如时延是否随机变化,反射路径线性还是非线性,以及运算量(电池)是否符合要求,则更为复杂。

     回到webrtc的回声时延估计,它采用的是gips首席科学家Bastiaan的算法。下面介绍一下该算法的主要思想:
设1表示有说话音,0表示无说话音(静音或者很弱的声音),参考端(远端)信号x(t)和接收端(近端)信号y(t)可能的组合方式有以下几种:(0,0),(0,1),(1,0),(1,1),
 (0,0)表示远端和近端都是比较弱的声音,(1,1)表示远端和近端都是比较强的声音,webrt的c代码默认其它两种情况是不可能发生的。设在时间间隔p上,即p=1,2,...,P,  频带q,q=1,2,...,Q上,输入信号x加窗(如汉宁窗)后的功率谱用Xw(p,q)来表示,对每个频带中的功率谱设定一个门限Xw(p,q)_threshold,
如果 Xw(p,q)  >= Xw(p,q)_threshold  ,   则Xw(p,q) =1;
如果 Xw(p,q) <    Xw(p,q)_threshold  ,   则Xw(p,q) =0;
同理,对于信号y(t),加窗信号功率谱Yw(p,q)和门限Yw(p,q)_threshold,
如果 Yw(p,q) >= Yw(p,q)_threshold   ,   则Yw(p,q) =1;
如果 Yw(p,q) < Yw(p,q)_threshold ,        则Yw(p,q) =0;
考虑到实际处理的方便,在webrtc的c代码中,将经过fft变换后的频域功率谱分为32个子带,这样每个特定子带 Xw(p,q)的值可以用1个比特来表示,总共需要32个比特,只用一个32位数据类型就可以表示了。
webrtc对参考信号定义了75个32位binary_far_history的数组存放历史远端参考信号,定义了16个32位binary_near_history的数组存放历史近端参考信号,最近的值都放在下标为0的数组中,使用 binary_near_history[15]的32位bit与binary_far_history数组中75个32位bit分别按位异或,得到75个32位比特数据,32位bit的物理意义是近似地使用功率谱来统计两帧信号的相关性。统计32位结果中的1的个数存于bit_counts中,接下来用对bit_counts进行平滑防止延时突变,得到mean_bit_count,可以看出  mean_bit_count 越小,则表明近端数据与该帧的远端数据越吻合,两者的时延越接近所需要的延时数值,用value_best_candidate表示。剩下的工作是对边界数值进行保护,如果value_best_candidate接近最差延时(预设),则表明数值不可靠,这时不更新延时数据;如果数据可靠,则进一步使用一阶markvo模型,比照上一次时延数据确定本次最终的更新时延last_delay.
Bastiaan的专利本身要比现有的c代码实现更为复杂,比如在异或的时候(0,0),(0,1),(1,0),(1,1)四种组合可以附加代价函数,而c代码相当于默认给(0,0),(1,1)附加权值为1,给(0,1),(1,0)附加权值为0;
另外c代码算法是按帧顺序依次对远端和近端数组异或,实际应用时也可以每隔1帧或2帧做异或,这样可以扩大搜索范围。
总的来说webrtc的时延估计算法复杂度比求相关大大简化,尤其适用于移动终端等对运算量比较敏感的场合进行回声消除。针对实际应用场合,算法还有提升的空间。

2) NLMS(归一化最小均方自适应算法
     LMS/NLMS/AP/RLS等都是经典的自适应滤波算法,此处只对webrtc中使用的NLMS算法做简略介绍。
     设远端信号为x(n),近段信号为d(n),W(n),则误差信号e(n)=d(n)-w'(n)x(n)  (此处‘表示转秩),NLMS对滤波器的系数更新使用变步长方法,即步长u=u0/(gamma+x'(n)*x(n));其中u0为更新步长因子,gamma是稳定因子,则滤波器系数更新方程为 W(n+1)=W(n)+u*e(n)*x(n);  NLMS比传统LMS算法复杂度略高,但收敛速度明显加快。LMS/NLMS性能差于AP和RLS算法。
    另外值得一提的是webrtc使用了分段块频域自适应滤波(PBFDAF)算法,这也是自适应滤波器的常用算法。
    自适应滤波的更多资料可以参考simon haykin 的《自适应滤波器原理》。

3) NLP(非线性滤波)
    webrtc采用了维纳滤波器。此处只给出传递函数的表达式,设估计的语音信号的功率谱为Ps(w),噪声信号的功率谱为Pn(w),则滤波器的传递函数为H(w)=Ps(w)/(Ps(w)+Pn(w))。

4)CNG(舒适噪声产生)
   webrtc采用的舒适噪声生成器比较简单,首先生成在[0 ,1 ]上均匀分布的随机噪声矩阵,再用噪声的功率谱开方后去调制噪声的幅度。

总的说来,webrtc的aec算法简单、实用、易于商业化,另一方面猜测c代码还有所保留。

 

由于工作需要,最近一直在研究WebRTC里的AEC算法。根据源码里面的fullaec.m文件,

总体来说,我认为该AEC算法是属于分段快频域自适应滤波算法,Partioned block frequeney domain adaPtive filter(PBFDAF)。具体可以参考Paez Borrallo J M and Otero M G

使用该AEC算法要注意两点:

1)延时要小,因为算法默认滤波器长度是分为12块,每块64点,按照8000采样率,也就是12*8ms=96ms的数据,而且超过这个长度是处理不了的。

2)延时抖动要小,因为算法是默认10块也计算一次参考数据的位置(即滤波器能量最大的那一块),所以如果抖动很大的话找参考数据时不准确的,这样回声就消除不掉了。

<think>好的,用户想了解AEC(声学回声消除)和AGC(自动增益控制)之间的区别。首先,我需要回顾一下这两个术语的定义和它们在音频处理中的作用。根据提供的引用资料,AEC主要用于消除通话中的回声,而AGC则是调节音频信号的增益,确保音量稳定。 首先,我需要确认AEC和AGC的具体定义。引用[1]提到,AEC回声消除,AGC是自动音频增益。引用[2]和[3]进一步说明,AEC处理回声问题,特别是在上行发送端,而AGC则用于音量均衡,可能同时存在于上行和下行。因此,两者的主要差异可能在于处理的问题不同:回声vs音量控制。 接下来,要分析它们的工作原理。AEC可能需要通过自适应滤波器来消除远端回声,而AGC可能使用压缩或限幅技术来调整信号幅度。引用[3]提到WebRTC中的AEC处理流程,包括回声消除、降噪和音量均衡,而AGC在接收端作为压限器。这说明两者的应用位置和算法不同。 然后,应用场景方面,AEC在视频会议、语音通话中尤为重要,防止回声影响对话。AGC则在需要保持音量一致的场合使用,比如不同说话者音量差异大的情况。引用[2]提到音频3A算法中的AEC和AGC分别处理回声和增益,这也支持了它们在流程中的不同阶段。 用户可能还想知道它们如何协同工作。例如,在WebRTC中,AEC先处理回声,接着ANS降噪,然后AGC调整音量。而AGC在接收端也可能用于限幅,确保播放的音频不会过载。这显示两者在信号处理链中的不同位置和顺序。 另外,技术难点方面,AEC需要处理双讲情况(Double Talk),即同时有本地和远端声音的情况,而AGC需要避免过度增益导致噪声放大或失真。引用[3]提到AECM处理流程中ANS会前置,这可能影响两者的协作方式。 最后,需要确保回答结构清晰,分点说明定义、原理、应用差异,并引用相关资料支持。可能还需要生成相关问题,帮助用户进一步探索,比如协同工作方式或优化方法。</think>### AEC与AGC的定义及差异分析 #### 一、定义对比 1. **AEC(声学回声消除)** 用于消除通话中因扬声器与麦克风耦合产生的回声,例如远端语音经本地扬声器播放后又被麦克风采集导致的回声问题[^3]。其核心是通过自适应滤波器预测并抵消回声信号。 2. **AGC(自动增益控制)** 通过动态调整音频信号的增益,使输出音量保持稳定。例如在多人会议中,平衡不同说话者的音量差异,或防止信号过载导致失真[^1][^2]。 #### 二、核心差异 | **维度** | **AEC** | **AGC** | |----------------|----------------------------------|----------------------------------| | **目标问题** | 消除声学回声 | 调节音量稳定性 | | **技术原理** | 自适应滤波、残余回声抑制 | 动态增益调整、压限器 | | **处理阶段** | 主要作用于上行发送端[^3] | 同时存在于上行发送端和下行接收端[^2] | | **应用场景** | 视频会议、语音通话 | 录音设备、实时通信系统 | #### 三、协同工作示例 在WebRTC音频处理流程中: 1. **上行信号**:先通过AEC消除回声 → ANS降噪 → AGC平衡音量。 2. **下行信号**:AGC作为压限器,防止播放音量过大。 此时,AEC解决回声干扰,AGC解决音量波动,两者共同提升通话质量。 #### 四、技术难点对比 - **AEC**:需应对双讲(Double Talk)场景,即本地与远端同时发声时的回声残留问题。 - **AGC**:需避免过度增益导致的噪声放大或语音失真,尤其在低信噪比环境下[^1]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值