voip电话中基于webrtc回声消除算法开发和实现

《voip电话中基于webrtc回声消除算法开发和实现》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现目录：’：’：妻誓篓兰要变⋯⋯⋯⋯⋯⋯i|IIIIIIIIHilllllIiIIIII⋯口39。4·2·2开发环境搭建⋯⋯⋯⋯⋯⋯!V2704474‘⋯394．2．3ALSA驱动⋯⋯⋯⋯⋯⋯⋯．．一二：一．：_．_I_一-=i⋯．414．3本章小结⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．44第五章测试结果及分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯455．1测试场景设计⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯455．2测试结果分析⋯⋯⋯⋯⋯⋯⋯．．．⋯⋯⋯⋯⋯⋯⋯465．2．1远端讲话话测试结果分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯465．2．2双端通话测试结果分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．485．2．3近端讲话测试结果分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．525．3本章小结⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．53第六章结论⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．⋯⋯⋯⋯⋯⋯556．1本文研究结论⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯556．2不足和展望⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．56参考文献⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．57致谢⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯59 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现摘要摘要当前随着网络带宽的发展，VoW(VoiceoverInternetProtoc01)技术及其应用也迅速发展。与传统电话相比，IP(InternetProtoc01)电话以其网络带宽利用率高，通话成本低，可灵活地提供丰富的增值功能而备受市场青睐。然而，在VoIP通话中，由于IP网络时延比较大，时延抖动比较大，使得回声现象比较严重，影响了通话质量和用户体验度。因此，要想使得VoIP广泛应用，必须提高其语音质量，那么就必须在因特网的语音传输过程中对回声进行处理。本文针对如何消除嵌入式可移动终端设备在VoIP通话中的回声进行了研究。深入分析了开源WebRTC项目的AEC(AcoustiCEchoCancellation)算法，对WebRTC的架构，其AEC算法的工作流程以及其各个模块的运行流程进行了详细的描述。选取了开源软件linphone作为VoIP软件程序，并对1inphone的组织架构，通话时的运行流程，以及如何将AEC算法移植到linphone软件中工作进行了详细的论述。选取了当前应用非常广泛的android操作系统作为软件测试平台，以及T工公司媒体功能非常强大的DM6446作为硬件测试平台，然后将在android代码树中编译出来的带有AEC功能的linphone应用程序，下载到DM6446开发板上进行实际测试。笔者和搭档分3组应用场景进行了多次测试，通过实际聆听语音效果和分析语音信号波形得出结论该AEC算法可以很好地应用到嵌入式设备的VoIP通话中。关键词VoIP，回声消除，android，WebRTC，linphoneIll 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现ABSTRACTWiththedevelopmentofnetworkbandwidth，VoIPtechnologyanditsapplicationsaredevelopingrapidly．Comparedwithtraditionalcall，IP(InternetProtoc01)callhashighnetworkbandwidthutilization，low—cost，andtheflexibilitytoprovidemanyvalue—addedfeatures，SOitiSgettingmoreandmoresupportfromthemarket．However，duringtheVolPcall，theechoisverygrave，whichdoseriousimpactoncallqualityanduserexperience。Therefore，inordertomakeVoIPwidelyused，wemustraiseitsvoicequality，thatiStosaywemusteliminatetheechointroducedbythetransmissionprocessthroughtheInternet。ThispaperhasdeeplyanalysedtheAEC(AcousticEchoCancellation)algorithmoftheopensourceWebRTCproject，andfocused012itsworkingperformanceonembeddedmobiledevices．ThearchitectureofWebRTCAECalgorithm，itsworkflowandeachmodule’Sfunctioncal1processweredescribedindetailinthepaper．Theopensourcesoftware1inphonewasselectedastheVolPapplicationanditsarchitecturewerediscussedindetailinthepaper．ThewidelyusedAndroidoperatingsystemwasselectedasthesoftwareplatform．TherI’SDM6446whichhasverypowerfulmediacapabilitieswasselectedasthehardwareplatform．ThenthiSpaperdescribedindetailhowtoporttheAECalgorithmtothelinphoneapplicationandhowtodownloadtheimagescompiledintheandroidsourcecodestreetotheDM6466hardwareplatformtotesttheworkingperformanceoftheAECalgorithm．Threegroupsoftestcasesweredesigned，eachrepresentanapplicationscenarioandeachWaSrepeatseveraltimes．ThroughanalysethewaveformsprocessedbytheAECalgorithmandfeedbackofpersonswhohave1istenedtheactualvoices，wecanconcludethattheAECalgorithmhasverywel1echocancellationperformanceandcanbeappliedtoVoIPapplicationsofembeddeddevices．KeywordsVoIP，AEC，android，WebRTC，linphoneIV 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第一章绪论1．1研究背景第一章绪论当前随着宽带网络的发展，VolP(VoiceoverInternetProtoc01)技术及其应用也迅速发展，skype，QQ，linphone正是代表之一。与传统电话相比，IP(InternetProtoc01)电话以其网络带宽利用率高，通话成本低，可灵活地提供丰富的增值功能而备受市场青睐。然而，在VolP电话中，近端通话者的声音被自己的麦克风拾取后通过网络传到远端，远端扬声器播放出来的声音被麦克风拾取后通过网络又重新发回近端。加上网络和数据处理等各种延迟的影响，使得近端通话者能听到自己的回声，严重影响了通话的质量和用户体验度。因此，要提高因特网的语音质量，就必须在因特网的语音传输过程中进行消除回声的处理”’。本章以下章节部分首先对VoIP技术进行简要介绍，然后分析VolP现在所面临的关键问题来说明本文的研究意义。I．1．1VolP介绍VoIP，顾名思义，是使用IP网络去传输语音信息。在百度百科口1上对VolP有着这样的定义：VoIP(VoiceoverInternetProtoc01)简而言之就是将模拟声音讯号(Voice)数字化，以数据封包(DataPacket)的形式在IP数据网络(IPNetwork)上做实时传递。VoIP最大的优势是能广泛地采用互联网，提供比传统基于SDH的电信电话业务更多、更好的服务。VoIP可以通过IP网络低成本的传送语音、传真、视频、和数据等业务。1995年2月，以色列的VocalTec公司推出的客户端软件IP电话“InternetPhone”标志着VoIP的诞生。自从VocalTec推出了软件“InternetPhone”后，很多公司都相继推出了类似的软件，比如微软的NetMeeting、IDT的Net2Phone、NetSpeak的WebPhone、英特尔的InternetVideoPhone。由于当时这种应用只限于在Internet上使用，因此人们通常将这种应用称为“Internet电话”。这一时期，使用者大多数是Internet上的网迷，由于技术还不完全成熟，语音质量基本上没有保证。其后，大概从1996年到1999年，在此基础上一些商用公司推出了Pc—Phone的业务，这种方式要求主叫方通过IP接入，然后通过IP网络连接到被叫方本地的PSTN(PubliCSwitched 万方数据VolP电话中基于WcbRTC的回声消除算法的开发与实现第一章绪论TelephoneNetwork)网络，这就要求被叫方只需拥有普通电话即可，这种方式在国际电话市场上占据了一定的市场。这时VolP进入发展期。随着网络带宽的提升，Wi-Fi(wirelessfidelity)技术的成熟和支持w卜Fi的终端移动设备诸如iphone和基于android操作系统的智能手机以及平板电脑的急速发展，VOIP不仅在PC上应用日益普遍化，在移动终端上占据的份额也越来越大。据国外媒体报道，Frost&Sul1ivan发现，在2008年，该领域的收入超过5．224亿美元。预计到2012年，此数字有望增长至6．573亿美元阁。VoIP广阔的商业前景被人们所发现，很多电信运营商将VolP技术引入到电信运营中，并取得了迅猛增长。1．1．2VOIP面临的问题和关键技术虽然VOIP发展速度很快，但是VOIP有着先天的质量缺陷。IP网络这种基于分组交换的技术相比于传统的基于电路交换的GSM网络，在业务的QoS(QualityofService)上很难保证嘲。传统的电路交换是面向连接的，一旦连接建立将唯一的占用一个连接，比特流连续地从源点直达终点。而分组交换是面向无连接的，基于分组转发机制，虽然具有着高效、灵活的特点，但是却无法保证传送的质量，比如报文的延时等，尤其在网络负载很大的情况下，延时和延时抖动都会急剧上升，并且存在丢包。VoIP技术是以IP分组交换网络为传输平台，再对语音信号进行采样、AD(Analog＼Digital)转换、编解码、IP分组打包等处理后，通过面向无连接的UI)P协议在网络上进行传输。在接收端经过相反的处理过程，最终将数字信号转换成模拟的语音信号。在这一系列的处理中涉及到的主要技术有：1)语音压缩编码技术一般人声的频率范围是300-3400Hz，即传输一路语音信号的频率范围也是300-3400Hz，因此一路普通的模拟电话通常要占用4KHz带宽，而对于一路数字电话，如果按照目前窄带每秒钟8000点采样，每个采样点用16bit表示，则传输过程中所占用的带宽为8000术16=128Kbps。可见相比于模拟信号数字信号的频带非常宽。用于传送语音信号的电缆传输信道是只允许比较低的频率成分通过的低通信道。当一系列数字脉冲信号通过带限的电缆信道时，其高频成分将会被滤去，使得最后的输出波形出现了失真。即码间干扰。根据奈奎斯特传输定理理想低通信道的最高码元传送速率为2w，w为信道带宽。则要无失真的传送一路速率为128kbps的数字电话，则信道带宽至少为64kHz。可见数字电话的语音信号占用的64kHz带宽是模拟信号4kHz带宽的16倍。根据奈奎斯特采样定理每秒钟8000次采样只是为了确保完整保留原始信号信息的最低采样率，实际过程中有 万方数据VolP电话中基于WcbRTC的回声消除算法的开发与实现第一章绪论可能会采用16000或者32000的采样率，即一路数字电话所占的带宽将会成倍增加。因此为了减少语音信号所占用的带宽就必须对数字语音信号进行压缩编码。2)静音检测技术静音检测，又称语音活动性检测(VAD，VoiceAativityDetect)，是为了将语音信号和噪声信号区分开来。之所以要采用静音检测有一下几方面的作用：a)节省带宽。根据相关实验统计，在用户进行实际语音通话过程主公，通话的甲乙双方并不会总是同时说话，一般只是一方说话另一方聆听，有时甚至双发都不说话。据相关论文引用的数据，由传统电话业务的统计结果来看，一方用户实际占用通话信道的时间不会超过整个通话时间的40％。而静音信号会像正常语音信号一样进行相同的采样编码占用相同的带宽，如果将静音和语音区分开来，那么可以对静音信号进行压缩编码，用占用极低带宽的编码即可表示静音信号，以极大的节省带宽资源。b)降低运算量。当检测到时静音时，可以将静音状态通知回声消除模块(下文提到)，那么回声消除模块便可以不用进行回声消除运算。根据静音占通话的比例这样一来可以降低60％的运算量。如果没有静音检测，在静音状态下仍然进行回声消除，则很容易引入运算误差。3)回声消除技术影响IP电话语音质量的因素有延迟、抖动、丢包。而延迟将引入回声，根据测试数据延时超过45ms便会引入回声。回声是影响VolP语音质量最关键的因素之一，因为这会严重影响用户体验度。上文已经提到，VolP中的语音传输采用分组交换技术实现，传送的语音信号要经过编码、压缩、打包等一系列处理，然后再因特网上经过很多个路由器到达目的地。因为分组交换的面向无连接特性，使得报文的QoS得不到保证。因而回声延时会根据网络负责状况而波动，导致回声的延迟抖动较大。与传统面向连接的PSTN电话相比，回声闯题显得尤其突出。在语音通话中所指的回声有两种，即电路回声和声学回声。声学回声正是本文在1．1节提到的回声，而电路回声是在网络端，由交换机的二四线转换引入的回声。目前随着回声消除技术的发展，电路回声已经可以很好的解决。而当前回声消除研究的重点，也已由电路回声的消除，转向了声学回声。典型的声学回声是一种大约10到15dB以下的寄生信号。这种级别的声学回声，若延迟在29ms以下不会引起人们的注意：若在40ms，那么线路另一端的人听起来对方就像在井里讲话一样；延迟时间超过40ms情况会更糟。ITU—T(InternationalTelecommunicationUnionforTelecommunication 万方数据voIP电话中基于WcbRTC的回声消除算法的开发与实现第一章绪论StandardizationSector)G．165建议电路平均往返时延超过45ms或ITU—TG．131建议单向端到端传输时延超过25ms时，应采用回声抑制措施。而本文所做的工作正是针对回声消除技术。1．2研究意义上面的1．1．3小节已经介绍了VolP通话中回声消除技术的重要性。但是目前国内解决回声消除的现状是各家都有自己的产品，而不同的产品在不同的运行平台上可移植效果差，而且很多都是硬件解决方案，即每在一台设备上运行就要产生额外的开销。本文则是本着软件上零成本解决这个问题的思路寻找一种算法。而WebRTC中的AEC算法正是这样一种解决方案。WebRTC(WebRealTimeCommunication)是一项在浏览器内部进行实时视频和音频通信的技术，是谷歌2010年以6820万美元收购收购GlobalIPSolutions公司而获得一项技术。谷歌与2011年6月3日宣布向开发人员开放WebRTC架构的源代码。其中包括声音处理一audio—processing模块，源代码在webrtc＼modules＼audioprocessing目录下。声音处理针对音频数据进行处理，包括回声消除(AEC，AcousticEchoCancellation)、AECM(AcousticEchoCancellationMobile)、自动增益(AGC，AutoGainContr01)、降噪处理等功能，用来提升声音质量。对于回声消除的两个模块AEC和AECM其区别是，AEC是给PC(PersonalComputer)机用的，而AECM模块是给移动终端等嵌入式设备用的。该AECM模块基于业界目前认为最先进的NLMS算法对回声进行估计，然后根据残差调整滤波器系数实现回声消除。回声消除效果很好，而且开源，可移植性强，如果能将此算法加以良好运用，则既能达到回声消除的目的又能减少大量人力物力成本。所以本文研究WebRTC的回声消除算法以使其有最理想的效果，对于提升VOIP语音质量和推进其广泛应用具有重要意义。1．3本文的主要内容本文介绍了当前回声消除的主要技术，并详细介绍了基于NLMS算法的WEBRTC开源AECM算法的实现流程。然后将该算法移植到基于SIP(SessionInitialProtoc01)协议栈的开源VOIP软件1inphone里。并在DSP开发板上测试了该算法的实际效果。测试结果证明该算法可以很好满足当前嵌入式中VOIP软件的回声消除需求。 万方数据vo口电话中基于WebRTC的回声消除算法的开发与实现第一章绪论1．4本文的章节安排第一章介绍了本文的研究背景。主要包括VOIP的概述介绍，其采用的SIP协议的介绍以及其所面临的关键问题和本文的研究意义等。第二章介绍了VOIP通信中回声的特点，以及针对这些特点当前所采用的解决方法。在此基础上详细的介绍了声学回声消除器的原理，结构和关键问题及对策。并在最后给出了NLMs算法公式的详细推导流程。第三章主要是对WebRTC的架构进行分析，重点分析了其AEC算法模块。首先给出了AEC的原理框图和工作流程图，然后细致的分析了笔者认为比较重要的四个模块，每个都给出了算法工作的流程图。第四章是描述如何搭建实际的工作环境去对算法进行实际测试。分软件和硬件两个方法进行描述，软件方面主要是描述了VolP软件linphone的工作流程和算法的移植，硬件方法主要是描述了开发板编译环境和启动流程，以及音频部分的ALSA驱动。第五章是设计测试场景进行了实际测试，并且抓取了实际通话中的波形图，对测试结果进行了分析。第六章是结语，主要总结了本文的工作和结论，指出了本文的不足并展望了未来。 万方数据VoIP电话中基于WcbRTC的回声消除算法的开发与实现第二章回声消除算法研究2．1VOIP通信中回声的特点与传统语音电话相比，因特网的语音传输是采用分组交换技术实现的一种全新的电信业务，其传送的语音信号发送过程如图2—1所示。图2—1VOIP语音传送流稃在因特网上传送语音首先是终端设备的声卡采集语音数据，采集到的数据以2进制格式存放到缓冲队列里，然后编码器从队列中读取数据采用某种编码格式进行编码；编码后的数据会放到另一个队列里缓冲，等待RTP(Real-timeTransportProtoc01)打包发送。而对于接收语音，首先是通过RTP接收对方过来的音视频数据包，然后送入队列缓冲：解码器会从该缓冲队列中读取数据进行解码，完成后数据送入队列缓冲，经重采样，均衡等一系列处理后送给声卡。而RTP包经过的传送网络是面向无连接的UDP，根本无法保证传送质量和延时。综上所述，这些处理会使得因特网上语音的回声路径的延迟和延迟抖动都较大。使得，因特网上的语音的回声问题比较严重，而且具有如下特点⋯。1)回声源复杂在第一章中已经提到回声包括两种电路回声和声学回声。正如第一章所说的电路回声是因为交换机的2-4线的转换。如图2—2所示。当然在第一章中也已经提到基于当前的回声消除技术这种回声已经不是处理重点了。6 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第二章回声消除算法研究图2-2电路回声示意图第二种回声源是声学回声(AcousticEcho)。正如第一章丌始所提到的声学回声是指扬声器播放出来的声音经过多次或一次或者没有经过反射后被麦克风重新采集后跟近端声音一起发回远端，这就使得远端谈话者在一段时间之后又能听到自己的声音。如图2—3所示。甲跟乙在互联网上进行语音通话，甲在自己的房间里产生的语音1被其麦克采集后经因特网传输到乙的房间，由乙的扬声器播放出来后又被乙的麦克风采集，跟乙自己的语音2一起又传输到甲的房间，导致甲在一段延时以后又听到了自己的声音。这种声学回声又可以分为直接回声和间接回声。其中直接回声是指扬声器播放出来的声音没有经过任何的反射又直接被麦克风采集。这种回声延迟最短，它的大小与远端说话者的语音能量，扬声器与麦克风之间的距离、角度、扬声器的播放音量以及麦克风的采集灵敏度等因素有关。间接回声是指扬声器播放出来的声音经不同的路径一次或多次反射后被麦克风采集所产生的回声集合。相比于电路回声，这种回声一方面会被周围物体的变动，例如人的走动改变反射路径进而影响回声路径，另～方面，VOIP除了应用于PC等固定终端还可以应用于诸如手机，平板电脑等移动终端，通话过程中，主被叫很可能都会大幅度改变位置从而改变回声路径，所以这种回声的特点是多路径、时变的。所以相比于电路回声处理起来难度要大很多。 万方数据VoIP电话中基于WcbRTC的回声消除算法的开发与实现第二章吲声消除算法研究‘簿；糕痢瓣≥ji|i忒影，一l一人秦0{Z{{＼、lI-IIl1一I／J—■_●■|．；／■Il靖盘，语音1图2-3声学回声示意图除了上述两种回声外，背景噪声也是产生回声的因素之一。2)回声路径的延迟大前面已经多次提到在因特网中的语音传输中，延时比较大，延迟抖动也比较大。导致因特网语音延迟的来源主要有三种：语音压缩延迟、系统处理延迟和分组传输延迟。其中主要的延迟是语音压缩延迟，例如在ITU—TG．723．1阳1标准中，压缩一帧的最大延迟可以达到37．5ms。系统处理延迟是指对语音包的封装时延及其在缓存区中的缓冲时延等。分组传输延迟主要是指在网络上通过UDP协议的传送延迟，这也是造成延迟的一个重要原因，因为实际测试表明，端到端的最大传输延迟有时可达250ms以上。3)回声路径的延迟抖动大语音在因特网上的传输采用的是UDP协议，UDP协议本身无法保证传送的Qo$，其传送质量会碎网络负载状况剧烈波动。特别是无线网络，其带宽的不确保性更大，再加上之前提到的回声路径、语音压缩时延、系统处理延迟，分组传输延迟，而且这些延迟的波动都较大，这就导致了回声路径大的延迟抖动，一般在20’50ms之间。 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第二章回声消除算法研究2．2VOIP中回声消除方法前一小节中在描述VOIP回声特点时提到voIP中的回声源主要是电路回声和声学回声。电路回声的消除技术发展到现在已经很成熟了，ITU—TG．168口1标准的回声消除器就能消除。声学回声由于其回声路径的延时比较大，延时抖动也很大旧相对于电路回声消除的难度要大很多。当前回声消除技术的研究热点也从电路回声消除转到了声学回声消除曲1。针对复杂的声学回声目前主要采用以下几种方法处理：1)周围环境的处理前一节已经提到声学回声跟扬声器播放的声音，周围环境的反射，已经麦克风的采集灵敏度有关，既然如此，控制声学回声最简单方法就应该是改善扬声器周围环境，尽量减少扬声器播放声音的反射。例如，可以在周围的墙壁上附加一层吸音材料，或增加一层衬垫以增加散射。根据上一节对直接回声和间接回声的描述，可见改善环境可有效地抑制间接声学回声n0。，但对直接声学回声却无能为力。2)回声抑制器回声抑制是使用较早的一种声学回声控制方法。其工作原理是通过简单的比较判决器，将己解码的准备由扬声器播放的声音与当前麦克风采集的声音的电平进行比较判决，如果准备由扬声器播放的声音高于某个阀值，就允许传至扬声器，同时关闭话筒；如果麦克风采集的声音电平高于某个阀值，则扬声器被禁止。通过这种工作方式，很明显可以看出，回声抑制器是通过非线性的打开关闭扬声器或者麦克风来实现回声抑制的。这样必然会导致有用的声音跟回声一起被抑制掉，同时也会导致部分本应由扬声器播放的声音因为扬声器被关闭而无法播放，从而严重影响声音质量““。随着高性能回声消除器的出现，这种方法己很少使用了。3)声学回声消除器声学回声消除器AEC(AcoustJcEchoCanceller)利用扬声器信号与由其产生的多路径回声的相关性，建立数学模型，来模拟回声路径。然后用此模型根据参考远端信号对回声进行估计，将回声估计值从输入的混合有回声信号的近端语音采样信号中减去，并且不断根据反馈误差信号来自适应修改滤波器系数直至误差为0即滤波器收敛，此时即可消除回声。根据存储远端参考数据大小的不同，AEC可用来消除各种延迟的回声”2。。至这种方法提出以来，已经有越来越多的方法来解决不同应用环境下的回声消除问题。虽然方法多样，但判定方法好坏的标准只有一个，那就是：收敛速度快、计算复杂度低、稳定性好和失调误差小。 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第二章回声消除算法研究虽然现在自适应滤波可以采用的算法多种多样，但所基于的经典算法凭借着其简单稳健的特点，经久不衰。如LMS(LeastMeanSquare)算法和NLMS(NormalLeastMeanSquare)算法。LMS算法是以最陡下降法为原则的，它是一种很有用且很简单的估计梯度方法，其最核心的思想是用平方误差来代替均方误差，并根据此来修改滤波器系数。这样～来输入信号的大小就会对算法的精度产生影响，即同样情况下，能量高的信号会引起梯度放大，而能量低的信号算法收敛速度较慢。将输入信号按照自身的平均能量进行归一化处理，就得到了归一化LMS算法，也称NLMS算法。NLMS算法仍保留了算法简单，运算量小，易于实现的优点并且从20世纪70年代后期，就成为商业化回波抵消器常采用的算法。声学回声消除器是当前解决声学回声的最佳方案。相比于回声抑制器它可以支持全双工通信，保证了通话的质量。而本文就是研究WebRtc中的AEC算法即是基于NLMS的声学回声消除器在基于SIP协议的VOIP在嵌入式平台上的应用。2．3声学回声消除器原理上一小节已经给出了声学回声消除器的简略描述，这一节将对其内部原理进行详细介绍。图2—4给出了声学回声消除器的基本结构。图2—4声学回声消除器基本结构其中，J，(疗)代表远端语音信号，d(玎)代表远端语音信号y(门)的回声，x(以)代表近端语音输入。具体过程：远端呼叫者在远端讲话产生的远端信号少(，z)被其麦克风采集，经IP网络传输传送到近端。近端的回声消除器即自适应滤波器JI、近端回声通道 万方数据VolP电话中基于WcbRTC的回声消除算法的开发与实现第二章回声消除算法研究会保存一定长度的y(刀)到其缓冲区。y(")被近端的喇叭播放出来，经过墙壁的反射和没有反射的信号一起叠加形成回声信号d(n)。该回声信号d(玎)又和近端语音z(玎)一起被近端麦克风采集，送往其内部的回声消除器。而该回声消除器会找到之前保存的远端参考信号y(n)，跟其滤波器的系数矩阵相乘，产生回声的估计值d(，z)，并从近端语音信号中将其减去。处理过的语音信号被发送至远端。最终远端呼叫者听到的语音信号“(胛)=x(n)+d(门)一d(行)。而d(胛)一d(门)便是误差信号P(咒)。理想情况下误差信号P(刀)应该为0。而自适应滤波器会根据e(n)的值依据一定的自适应滤波算法调整其系数。从上述过程我们可以发现，在进行回声消除即自适应滤波的过程中有个问题需要考虑即什么时候对自适应滤波器进行反馈。因为滤波只能针对回声信号，所以当近端语音信号x(栉)存在时，滤波输出与参考信号相减得出的误差信号z(刀)+d(，2)一d(豫)并不是真正的误差，所以如果这是对自适应滤波器系数进行反馈只会造出滤波效果越来越差。所以当有近端语音信号存在时是不能进行系数反馈更新的。远端语音信号在近端的喇叭播放出来经过反射或者没有发射最后形成的回声信号与其参考信号有很大的相关性。可以这样认为d(，2)=r《y(，z))。面函数r唯一的对应着回声路径。当下VOIP应用的场景很多都是诸如iphone，IPAD，HTC等智能手机和平板电脑的移动终端上。呼叫者的移动性是很大的，这就造成了回声路径快速变化。所以用于做回声消除的自适应滤波算法必须要有快速的收敛速度以准确估计当前的回声路径。纵观当前VOIP的应用场景，诸如远程会议系统，语音视频聊天工具，用在智能手机或者平板电脑上的VOIP应用软件，我们可以发现这些VOIP应用具有以下特点“”：1)整个传输过程中最多只存在两路回声；2)在正常的过程中，不论是哪一端，背景噪声的变化都不会很大：3)采用的是非点对点技术传输视音频数据；4)实际应用过程中，网络条件并非都很好，而且其他多媒体数据会占用较高的网络带宽，如果可以进一步考虑降低网络带宽使用率的方法，有助于提高系统性能。综上所诉可以总结声学回声消除器面临的关键问题如下：1)语音检测。根据不同的语音检测结果来控制自适应滤波器的工作。2)静音检测。通过该技术可以大大减少音频数据发送量，降低网络带宽，缓解网络拥塞，同时能更进一步提高的回声消除效果。3)自适应滤波器的选取及所使用的自适应滤波算法。 万方数据v0IP电话中基于WebRTC的回声消除算法的开发与实现第二章回声消除算法研究2．3．1双端检测在回声消除的过程中，首先要进行语音检测，其目的是用来确定三种语音状态：近端讲话状态、远端讲话状态和双端讲话状态(doubletalk)。自适应滤波器将根据判断出的不同的语音状态对语音信号做出相应的处理。1)近端语音状态：仅仅存在近端语音的状态。在这种状态下，远端没有语音所以近端麦克风就不会录入其回声，故此时滤波器既不进行滤波，也不进行系数更新。2)双端语音状态：近端和远端语音同时存在的情况。这种状态正是上--d'节提到的何时进行滤波器系数更新的情况。远端语音信号存在，故回声信号也存在，所以在此状态下要进行滤波。但是此时不能进行滤波器系数的更新，因为此时的回声残留信号会很大，因为它中间不仅仅包含着真正回声残留信号，还包含了近端语音信号。如果此时滤波器还根据这个值进行系数更新，势必会造成回声估计的极大偏差，引起回声消除性能的下降。3)远端语音状态：只有远端在讲话的情况。在这一状态下回声信号以及滤波器输出的回声误差信号都是准确的，所以此时滤波器既要进行滤波，又要进行系数更新，而且滤波器系数要利用这一状态迸行快速收敛。状态1至于实际的回声消除是没有意义的。因此我们可以更加简单的将语音状态分为双端语音状态和非双端语音状态。当判断为双端语音状态时，自适应滤波器只对回声信号进行滤波，而不会更新滤波器系数。否则，自适应滤波器既要对回声信号进行滤波，又要进行系数更新。虽然目前针对语音双端检测的方法种类很多，但是归结下来可以讲这些算法分为两类：基于能量的算法和基于语音信号相关度的算法。1．基于能量的检测算法该类算法主要通过计算短时能量的方法来确定是否存在近端话音信号。这其中又涉及到两种具体的实现方法：1)基于能量对比的方法。其代表是传统的GEIGEL算法n“。判定一个状态是双端语音还是非双端语音，实际上就是判定在远端语音存在的同时是否还有近端语音。我们很自然想到的一种算法就是把播放出来的远端语音信号能量与近端麦克风采集到的语音信号能量比较，采集到的信号的能量如果比扬声器播放的信号的能量都高的话则一定存在近端语音。而GEIGEL算法的思想正是基于此。由于回声延迟的存在以及信号能量的增加需要一定时间的缘故，GEIGEL算法会把麦克风的信号同过去一段时间内扬声器的声音信号中的最大值进行对比，而并非与当前时刻的扬声器信号对比，以此保证了检测的准确性。具体来说，如果当前采 万方数据voP电话中基于WebRTC的回声消除算法的开发与实现第二章回声消除算法研究样时刻n麦克风拾取到的声音采样信号的幅度的绝对值要比n—l，n一2⋯n—N等连续N个采样点扬声器播放出来声音信号幅度的绝对值的最大值与系统对语音信号的衰减系数的乘积大的话则证明双端语音存在。2)基于能量平均的方法。该算法是通过计算信号能量的比值而检测，其依据的公式如下：成。i麓E，巨(0一1)公式(O一1)中，E。，E，ee分别代表了远端信号，回声估计信号和误差信号的能量。当风>1时则检测到双端语音状态。2．基于语音信号相关度的检测算法这类算法的基本原理是依据近端语音信号、远端语音信号、回声信号之间相关度的不同进行判断。文献[13]中提到一种两矢量夹角法的算法。其基本原理就是把自适应滤波器的输入回声参考信号和输出回声估计信号每～帧的采样值作为2个矢量，实时计算两个矢量的夹角。当没有近端语音信号时，该夹角的余弦值基本为l，否则会明显小于1。因此可以设定～个阈值，当该夹角的余弦值比该阈值小时则判定为双端通话状态。2．3．2静音检测在第一章中已经提到过V01P这种数字语音信号相比于传统的模拟语音信号带宽增加了16倍⋯3。所以在V01P中采用一些技术来降低带宽还是很有必要的。而静音检测的主要目的就是为了降低网络带宽占用率，缓解网络拥塞，减少网络延迟，这样将能够进一步减少回声，提高回声消除效果，改善语音传输质量。人在通话过程中声音可以分为静音和话音两部分，在第一章中同样也曾提到据统计在语音通话中用户实际占用信道的时间不会超过40％，也就是说平均60％时间是静音。而在多人交谈时，即电话会议中，同一时刻，一般只有～人说话，而其它的人基本上都是静音。而这些静音却要和正常的语音数据一样经过采集、编码占用同样的传输带宽。不仅耗费带宽也耗费终端的CPU性能。所以在VolP中必须采用静音检测技术以从语音信号流里识别和消除长时间的静音期，达到节省带宽，降低终端CPU占用率的目的。带宽占用率下降了，语音信号端到端的传输延时自然也就降低了，从而也就提高了语音质量。在实际使用中，通常是在检测到静音后用特殊编码取代告知对端是静音，这样在对端播放时就会出现长时间的静默，从而使用户感到很不舒服。因此实际上在发送端检测到静音时通常会加上一些使用户感觉舒服的背景噪声，即所谓的舒 万方数据VoIP电话中基于web砌rC的回声消除算法的开发与实现第二章回声消除算法研究适噪声(ComfortableNoise)。这样接收端在播放时听起来就不会那么突兀。所以实际应用中完整的静音检测技术是由语音活动性检测和舒适噪声生成器两部分来实现的：1)话音活动性检测这部分是通过采用特定的语音判决算法来判定当前的信号是否是语音信号。如果是，就按照所采取的语音编码算法比如G．71l，PCMU等进行编码；如果不是，则采用极低的比特率进行静音编码，或者不发送任何比特。2)舒适噪声生成器CNG(ComfortNoiseGenerator)这部分主要是根据当前环境的背景噪声以及语音信号强度按照特定的算法来生成噪声。这种设计主要是要满足语音和噪声之间的平滑过渡，使得用户听起来不会太突兀。一般静音检测需要满足以下五个要求“引。(1)能在不影响话音质量的前提下去除尽可能多的静音。(2)因为必须用软件来实现，所以它必须有较低的复杂度，较低的处理延时。(3)因为它在一个有限资源的环境中实现，所以它需要一个容量较小的缓冲区。(4)它必须能在一帧中辨认出语音和静音，因为多存储一帧语音信号将增加端对端的时间延时。(5)它应该更擅长检测长时间的静音，而不是短暂的静音。静音检测技术经过很多年的发展，已经有很多成熟的静音检测算法投入到实际应用中，这些算法一般是利用语音和噪声在信号特性上的不同，通过软件计算方法提取这些特性值并与一定的阀值进行比较，从而得到判决结果。最常用的VAD算法是基于时域的短时能量法和过零率n引。2．3．3NLMS自适应滤波算法从第2．2节及本节开头对声学回声消除原理的介绍中，我们可以看到声学回声消除器最核心的自适应滤波器实际上是实现了一种算法，该算法就是可以用其抽头系数估计出回声路径，并用误差信号作为反馈去自适应的调节其系数。丽采用什么样的自适应算法去实现对回声路径最精确的估计以使输出的误差信号最小便是本小节要介绍的。在2．2小节中已经提到，LMS算法凭借计算量低，稳定性和算术特性好的特点，得到了广泛的应用。下面介绍一下LMS算法数学理论推导以及在它的基础上改进的NLMS算法。LMS算法实际上是一种“下降算法”。“下降算法”有两种实14 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第二章回声消除算法研究详细描述采用自适应梯度算法推到出来的LMS算法的迭代公式。首先给出下降算法的迭代公式为矗(门+1)=^(甩)+∥(行+1)v(珂+1)(O一2)公式(0—2)中向(玎+1)为第n+1次迭代的滤波器系数向量，∥(胛+1)为第n+1次迭代的更新步长，而v(疗+1)为第n+1次迭代的更新方向。最常用的下降算法为梯度下降法，常称“最陡下降法”。在这类算法里，更新方向向量v@+1)取作第n次迭代的性能曲面负梯度．vf亭fnll，ff门1表示性能指标，在回声消除里即是估计的误差信号的大小，即误差信号P(胛)的能量。所以v(告(玎))具体表达式如v(乎(疗))：号孝：![竺!三}兰!旦‘。一3’对公式‘0-3’中未E(P(”)2)有：有：刍E(已(聆)2)：2E{e(刀)刍P(以))‘。一4’而对P(玎)有：P(聍)：d(聍)一0(行)(0-5)公式(o一5)中d(玎)代表回声信号，0(门)代表回声信号的估计值。则对0(，z)．N-I(0-6)0(以)=∑彬(胛一f)=磁DⅣ(刀)公式(0-6)中N代表滤波器抽头系数的个数。将公式(O一6)代入公式(0—5)中豪P(玎)=一巩(朋)在将公式(0-7)代入公式(0-4)并结合公式(0-3)可以得到：V(孝(玎))=一2E{P(行)巩(船))这样可以得到系数‰的一种迭代方式：风(厅+1)=风(疗)+口E湫刀)珥(胆)}(0-7)(0—8)(o-9) 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第二章回声消除算法研究对于交互项E{P(，z)pⅣ(挖)}，由于它是未知的，我们只能使用它的估计值，一种直观的估计为：1K-I(0一lO)E{P(疗)DⅣ(胛)}=专∑P(聆一f)巩(聆一f)公式(O—10)中K表示我们使用的数据的长度。将公式(0-i0)代入公式(0-9)即可以得到用于估计的最陡梯度算法。由于公式(0-10)在进行估计时对于每一次迭代要用到K次乘法和K-1次加法，运算量较大。而LMS算法便在这个基础上进一步简化，直接用瞬时值来代替期望值，即E{已(胛)巩(n)}：P(")巩(胛)(0-11)将公式(0—11)代入公式(0-9)即可以得到LMS算法的迭代公式：巩(刀+1)：风(聍)+口P(刀)DⅣ(刀)(o-12)这就是LMS算法的迭代式。这种方法可以看作最陡梯度法的一种近似。它虽然是一个近似式，却能够在一定程度反映输入数据的统计特性随着时间的变化。由于它迭代的计算量小，所需要的存储器空间也小，因而在实践中被大量应用。然而由于L／dS算法采用瞬时值代替期望值，也随之带来了随机波动，即输入信号的大小对LIdS算法存在影响，同样情况下，能量高的信号会引起梯度放大，而能量低的信号将会造成算法收敛速度较慢。将输入信号按照自身的平均能量进行归一化处理，就得到了归一化L／dS算法，也称NLMS算法。其迭代公式如下：向(胆+1)=Jiz(n)+帮‘。一13’公式(0-13)中p2(疗)=专∑x2Q—f)，N为滤波器的系数数量即回声消除器的长度，∥是可变的步长因子。2．4本章小结本章首先概述了VOIP通信中回声的特点，针对这些特点列举了当前常用的一些处理方法。并对应用最广泛效果最好的声学回声消除器做了详细的介绍。详细讨论了声学回声消除其中需要解决的语音检测，静音检测和自适应滤波3个问题，依次介绍了当前针对这些问题所采用的解决方法。在本章最后一个小节笔者介绍了NLMS算法的由来并给出了详细的推导过程。 万方数据Vom电话中基于WobRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现3．1WebRTC简介正如第一章中所介绍的，WebRTC(WebRealTimeCommunication)是一项在浏览器内部进行实时视频和音频通信的技术，是谷歌2010年以6820万美元收购收购GlobalIPSolutions公司而获得一项技术。谷歌与2011年6月3日宣布向开发人员开放WebRTC架构的源代码。WebRTC之所以有着广泛的应用前景，跟其优势是截然相关的。简略来说WebRTC实现了基于网页的视频会议，标准是WHATWG(网页超文本工作小组，WebHypertextApplicationTechnologyWorkingGroup)协议，目的是通过浏览器提供简单的javascript就可以达到实时通讯能力。此外，WebRTC提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。总结来说WebRTC的主要优点如下：1)没有插件2)对硬件无特殊要求，只需要设备支出浏览器即可使用该技术3)有很强大的功能，包括：a，点到点的视频播放b．支持视频会议C．支持广播d．支持在线游戏e．支持语音识别f．支持客户白助服务3．1．1WebRTC架构通过上面的分析我们已经了解了WebRTC的主要功能。也可以看到WebRTC的核心技术主要包括音视频的采集、编解码、网络传输、显示等功能。下面会进一步对WebRTC的组件架构进行分析。首先给出WebRTC的架构图。 万方数据VolP电话中基于WebRTC的吲声消除算法的开发0实现第三章WebRTC中AECM笺ii兰婴语音引擎视频引擎嗍络传输图3—1WebRTC架构图互联刚由图3—1可以看出WebRTC主要包括音频处理，视频处理和网络传输3部分组件。WebRTC的音频部分，包含编解码、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控等功能。WebRTC的视频部分，包含采集、编解码、加密、媒体文件、图像处理、显示、网络传输与流控等功能。在下一小节中将对WebRTC的主要组件做详细介绍。3．1．2WebRTC的功能组件上一小节中已经说明WebRTC主要包括音频处理，视频处理和网络传输3部分组件，下面将从这3个部分依次介绍其内部功能单元刘览器 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现1．语音引擎语音引擎单元为音频媒体提供了一个框架，包括从声卡一直到网络的通道。1)iSAC／iLBCiSAC是一种宽带语音编解码协议。它采用16kHz或者32kHz的采样频率，其比特流可以自适应的从12kbps到52kbps。iLBC是一种窄带语音编码协议。由IETFRFC3951和IETFRFC39513952所定义。它采用8kHz采样频率，编码出的码流比特率有两种，20ms一帧的比特率是15．2kbps，30ms一帧的比特率是13．33kbps。2)NetEQNetEO是一种先进的抖动缓冲器及丢包补偿模块，能够显着提高IP电话系统的音质，并把延迟减至最小。与其它同类方案相比，这款先进的语音处理软件可减少抖动延迟达30至80mS，即使在不良的基础设施中也能够获得出色的音质n71。3)AEC声学回声消除模块，这在前面一些章节里已经详细介绍过来，此处不再重复。4)降噪模块该模块基于当前的数字信号处理技术，用于消除VOIP通话中与语音一起的高斯白噪声或者有色噪声等各种噪音。2．视频引擎1)VP8视频压缩解决方案厂商On2Technologies公司现已推出最新的视频压缩格式On2VP8。On2VP8是第八代的On2视频，能以更少的数据提供更高质量的视频，而且只需较小的处理能力即可播放视频，为致力于实现产品及服务差异化的网络电视、IPTV和视频会议公司提供理想的解决方案。目前，On2已被Google以1亿美元收购。2)视频抖动缓冲动态抖动缓冲区。可以隐藏抖动和丢包对整体视频质量造成的影响。3)图像增强类似于回声消除，降噪等语音增强技术的图像增强技术可以提升视频质量，例如可以消除摄像头采集到的原始数据中的噪声。3．网络传输1)RTP协议栈实时传输协议RTP是针对因特网上多媒体数据流的～个传输协议，它是由IETF作为RFCl889发布。其目的是提供时间信息和实现流同步。但是RTP本身 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现只保证数据的实时传输，并不能为数据包的按顺序传送提供可靠的传送机制，也不提供拥塞控制或流量控制等控制机制。实时传输控制协议RTCP负责管理传输质量，其工作机制是：各个会话参与者在一个RTP会话期间，会周期性地发送承载有统计信息的RTCP包，这些统计信息包含已经发送的数据报文的数量、丢失的数据报文的数量等，当服务器收到这些信息后边可以根据这些信息来动态地调整传输速率等以适应网络状态。一般PTP会和RTCP配合使用，这样可以有效以最小的开销反馈传输性能信息，从而最优化传输效率，故特别适合用于实时数据在因特网上的传送。2)STUN／ICESTUN(SimpleTraversalofUDPoverNATs，NAT的UDP简单穿越)是由RFC3489定义一种网络协议，通过它，客户端可以找出自己的公网地址，查出自己位于哪种类型的NAT，所绑定的Internet端口等信息。从而可以再两个同时处于NAT路由器之后的主机之间建立UDP通信。ICE是一种面向对象的中间件平台。它整合了STUN和TRUN。ICE为构建面向对象的客户～服务器应用提供了工具、API和库支持。通过使用STUN和ICE可以在各种各样的网络上建立链接。3)会话管理。不同于其他层，这是一个抽象层。主要用于会话的建立和管理。这一层的是实现由应用程序开发者决定。3．2WebRTC中的AEC模块上一小节已经介绍了AEC模块在WebRTC架构中的详细位置。下面将结合AEC模块的处理流程对算法傲详细介绍。WebRTC中在其audioprocess代码中有两个AEC模块，一个放在AEC／目录下，另一部分放在AECM／目录下。这两部分的区别是AEC是用在PC端的，AECM是适用在嵌入式设备上的。两者的区别比较大，因为PC设备相比与嵌入式设备，无论是在计算能力和声音处理流程上区别都很大。PC支持浮点运算，而嵌入式设备因为成本原因，一般都会选择定点运算的处理器，在计算精度上定点运算相比于浮点运算会引入一定误差。在声音的处理逻辑上，由于PC设备很难做好同步等诸多原因PC设备要比嵌入式设备复杂的多。但是两部分的数学和声学原理都跟前面章节介绍过的是一样的。本文主要研究VOIP在智能手机、平板电脑等嵌入式设备上的应用，故选择AECM算法做切入点。20 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现3．2．1AECM算法框架本小节首先给出AECM的原理框图，如图3—2所示。图3—2AEC原理框图其中，NLP(NonLinearProcess)非线性处理，是对残留回声的进一步削弱。舒适噪声发生器是在当检测到静音的时候用编码率很低的舒适噪声来模拟静音，这两部分在后面章节会有详细介绍。图3—2详细描述了AECM的处理逻辑。远端信号，，。、经过网络被近端设备接收，近端设备的回声消除模块会保留一份作为参考信号，同时近端设备的扬声器会播放出来该远端信号。播放出来的信号经过0次或者多次反射形成回声信号df，z)与近端信号x(玎)一起被近端麦克风采集，形成采集信号yf门)。回声模式选择器会对当前模式进行判断，如果远端信号确实存在，即回声存在，则近端采集到的信号yf，?)会进入自适应滤波器，由自适应滤波器产生回声估计信号0fnl。如果是近端信号，，"、不存在，则会保存该系数。如果近端信号存在则会使用保存的系数对当前混合信号滤波。并由辅助滤波器产生回声估计信号j，。．、。然后近端采集信号1，f门1与回声估计信号0f，21相减的结果会反馈给模式选择器，然后模式选择器调用AEC控制器来决定是否进入NLP模块。当这些都完成之后AEC 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第三章WcbRTC中AECM算法实现控制器会根据静音检测结果决定是否启用舒适噪声发生器来产生舒适噪声。这些处理都完成之后的信号便是回声消除器的输出信号。即可经过降噪编码之后发往远端。但是现在AECM在AEC控制器这一块并没有很好地实现。总结起来主要有以下两点：1)没有实现实时的本端的静音检测。AECM在其算法中只是对远端信号做了语音活动性检测，以用来决定是否需要滤波。然后根据滤波后的误差大小去推断是否有本地语音，这种判决误差是很大的。不仅如此，判决的结果也不会反馈给AEC控制器，以使其可以控制舒适噪声发生器。这样造成的结果就是虽然通话中有很长的静默期，但语音编码速率并没有降低。2)没有实现双端检测DTD(DoubleTalkDetect)。这一点是跟本端实时的静音检测本质上是相同的。只有对本端和远端做了高质量的语音活动性检测，才能准确的确定回声消除模式，也才能准备的实现滤波。即只有远端信号的时候就对远端信号滤波同时更新滤波器系数，面当远端信号和近端信号都有的时候则用缓存的滤波器系数对混合信号进行滤波。该AECM模块没有实现这种双端检测，就导致将近端信号一起当做回声信号滤掉，结果是远端呼叫着逐渐昕不到本端的声音。3．2．2AECM算法流程首先给出AECM算法的函数的主要调用关系图，如图3—3所示。图3—3AECM处理流程框架 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现其中FRAME指的是一帧。这可以由用户自己定义，该参数是由调用WebRtcAecmProcess的VolP应用程序设置的。本文采用的VolP应用程序是Linphonen引，采用的采样速率是每秒8000点，PCM格式是$16一LE，即每点16比特。本文采用的一帧是lOms的数据即80个采用点。以lOms的数据位单位进行处理，是因为语音信号在lOms“30ms上是短时平稳的n61，即其物理参数特性是保持不变的。BLOCK指的是块，AECM算法中默认设置的是每块64个采用点，这是因为FFT(FastFourierTransformation，快速傅里叶变换)是基2的，即以2“为单元。由图3—3可以看到外部程序在调用WebRtcAecm之后，进入_ProcessAECM算法，算法首先会读取要处理的近端数据，然后会估计近端和远端参考信号之间的延时，之后调用WebRtcAecm_ProcesFrame对信号按64点进行分块，之后由该函数调用WebRtcAecm_ProcesBlock，并在WebRtcAecm_ProcesBlock里面实现回声消除的功能。下面对webRtcAecm_ProcesBlock函数进行详细分析来给出3。2．1小节中各个功能模块的实现。3．2．3AECM算法功能模块实现前-4,节已经提到AECM算法的各个功能模块的实现都是在WebRtcAecmProcesBlock函数中完成的。本小节就结合这个函数的处理流程以及其调用到的函数来进一步阐释AECM算法的处理逻辑，并且逐一分析每个功能模块的实现。设计到的技术点有64点FFT的实现，以及为了防止频谱泄露和栅栏效应所选择的窗函数，步长的更新算法，远端语音的活动性检测，非线性处理算法，和舒适噪声生成机制。首先给出WebRtcAecmProcesBlock函数的处理流程，如图3—4所示。 万方数据VolP电话中基于WcbRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现图3—4WebRtcAecm_ProcesBlock处理流程图3—4中各个函数所实现的主要功能依次如下：TimeToFrequencyDomain：对近端和远端信号做快速傅里叶变换：UpdateFa州istory：更行远端信号频谱历史，以便和近端信号频谱进行对齐；WebRtc—DelayEstimatorProcessFix：估计近端信号和其远端参考信号之间的时延，以便和近端信号频谱进行对齐：AIignedFarend：根据计算的时延对齐远端参考信号和近端信号的频谱；WebRtcAecm_CalcEnergy：计算一个块内近端信号远端信号和估计回声信号的能量，并进行远端语音活动性检测；WebRtcAecm_CalcStepSize：计算NLMS算法系数迭代的步长；WebRtcAecm_UpdateChannel：更行自适应滤波器的抽头系数； 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现CalcSuppressGain：计算抑制增益供噪声抑制使用；NLP：NLP是直接在WebRtcAecm_ProcesBlock中实现的，并没有独立出来一个函数，但是由于那部分代码在功能上很独立，笔者在此将其归结为NLP函数。ComfortNoise：根据背景噪声进行模拟产生舒适噪声：笔者认为其中比较重要的函数有：TimeToFrequencyDomain，WebRtcAecmCalcEnergy，WebRtcAecmUpdateChannel，NLP，ComfortNoise。分别对应快速傅里叶变换，远端语音活动性检测，系数更新算法，残余噪声非线性处理以及舒适噪声产生。1．快速傅里叶变换AECM算法实现快速傅里叶变换采用的是按时间抽取的傅里叶变换。即整个26=64点的运算可以分解为6级的2点的离散傅里叶变换。这种按时间抽取的傅里叶变换每一级的输出都可以作为下一级的输入，只需要64个寄存器去保存数据。按时间抽取的傅里叶变换变换前后频域和时域点的对应上是倒位序的，所谓倒位序即点的序号转换为二进制后其比特位是逆序排列的，例如(00000001)。，倒位序后对应(10000000)。。这实现这种按时间抽取的快速傅里叶变换之前要对时域输入1，2⋯64需要倒位序后在进行傅里叶变换。这种快速离散傅里叶变换会引入频谱泄露和栅栏效应“⋯，为确保傅里叶变换的准确度必须加窗。AECM选择的是hanning窗。Harming窗也称升余弦窗，长度为N的离散Hanning窗时域表达式为：％㈤：*。s『制胪0，l，．．．Ⅳ-，∞‘1创其离散时间傅里叶变换为：％(∞，=三砾(缈)一三陬(彩一斋)+％(缈+等)]∞。1勋公式(O一15)中，％f缈)为矩形窗的频谱函数。矩形窗属于时间变量的零次幂窗。矩形窗在快速傅里叶变换中使用最多，通常时域截短即相当于加矩形窗运算。矩形窗的优点是主瓣较集中，缺点是旁瓣较高，并有负旁瓣，导致频域变换中引入高频干扰和泄漏，甚至出现负谱现象。Hanning窗可以看作是3个矩形窗的频谱之和。与矩形窗相比，Hanning窗主瓣变宽，旁瓣则显著减小。在防止频谱泄漏上，Hanning窗明显优于矩形窗。2．远端语音活动性检测AECM算法在WebRtcAecm_CalcEnergy函数中对远端信号做了语音活动性检测。之所以要进行远端语音活动性检测，是因为当远端信号很小时，回声信号的信噪比会很低，这时很难将回声信号和背景噪声信号区分开，如果再进行自适应 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现滤波的话，将会导致自适应效果很差。AECM算法中远端语音活动性检测遵循两个原则，第一个是将farLogEnergy与VAD判决门限farEnergyVAD的值进行比较，其中farLogEnergy代表～个块内远端信号的能量。如果farLogEnergy大于farEnergyVAD则认为有远端语音，反之则认为远端语音不存在。另外一个是对远端频谱的每个点，即该点对应频域点的幅值设置一个CHANNEL—VAD，在系数更新时会进行判决，只有当该点频域幅度值大于CHANNEL—VAD才会对该点进行系数更新。3．系数更新算法AECM算法的自适应滤波器部分采用的是NLMS算法，这一点在第二章里已经提到过。在第二章的2．3．3小节本文给出了NLMS算法的公式。下面就给出在该算法的理论基础下AECM里自适应滤波器系数更新的详细流程，如图3—5所示。系法图3—5系数更新流程图26 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现其中，channel_Adapt[i]表示自适应滤波器第i个点的自适应的系数。这里会保存两个系数，一个是channelAdapt[i]，另一个是channel—stored[i]是上一次存储的系数，是在步长为0的时候使用的。Near[i]和far[i]分别代表近端和远端信号当前所处理的这一个块中的第i个点。在本节开头已经提到过了每个块包括64个点。C—VAD代表在第2点远端语音活动性检测中提到的CHANNELVAD，而VAD指通过farLogEnergy大于farEnergyVAD比较判决出来的VAD的值。MSE(MeanSquireError)指均方误差。Adapt和stored的MSE是指分别用adapt和stored的系数计算出来的均方误差。这里是用绝对误差代替的，即近端输入和估计回声之差的绝对值。T指MSE判决门限，它会根据当前的MSE值进行更新。黄色框内是系数更新算法的流程，只有当迭代步长不为0是才会执行。右侧是根据vAD判决结果以及MSE值所进行的系数保存或更新流程。4．残余回声非线性处理由于滤波器系数的误差等原因，经AEC处理后的信号可能会有少量残余回声不能得到完全抑制。在存在近端语音时，由于近端语音的功率一般比残余回声的功率大的多，故近端语音可以在一定程度上掩盖后者。但是在没有近端语音时，残余回声就会干扰正常的通话了。而非线性处理便可以将这些残余回声完全去掉。一般来说，非线性处理的原理就是当回声信号能量小于一个预先设定的门限值的时候就用舒适噪声替代。AECM中不是直接对残余回声信号进行处理啊，而是直接对自适应滤波器的系数进行处理。下面给出具体判决流程，如图3一l所示。其中，TH代表高门限，算法中设定其值为l，T。代表低门限，算法中设定其值为0．2。Hnl[i]表示64点的系数数组第i个系数的值。 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第三章WebRTC中AECM算法实现图3—6非线性处理流程5．舒适噪声产生对残留回声信号进行非线性处理后，常常给远端听者造成一种完全寂静的感觉，远端听者会误认为线路中断。为避免这种情况发生，需要给远端听者提供一个与近端背景噪声电平相适应的噪声，该噪声称为舒适噪声。舒适噪声的生成主要有三种方法，白化滤波法，背景噪声合成法，特定频谱噪声法啪3。白化滤波法是在检测到残余回声时，实时计算残余回声的频谱和功率，并且构造白化滤波器，对残余回声作白化滤波并且作增益控制，使输出在听觉上近似白噪声，强度和背景噪声类似。这种方法的问题是计算量非常大，而且由于白化滤波器只能每隔 万方数据V0m电话中基于WebRTC的回声消除算法的开发与实现第三章W曲RTC中AECM算法实现一段时间更新一次系数，在这段时间间隔内残余回声频谱的变化仍然会反映到舒适噪声中，所以听觉效果并不理想。特定频谱噪声发是用特定频谱的噪声取代残余回声，具体就是用符合噪声特性的频谱滤波器来修正白噪声发生器产生的白噪声，并用背景噪声功率对其做自动增益控制。背景噪声合成法对残余回声作背景噪声检测，对背景噪声进行频谱分析，并且建立一个和背景频谱特性近似的线性预测滤波器。在检测到残余回声时，用高斯白噪声激励线性预测滤波器，产生频谱类似背景噪声的舒适噪声替换残余回声。AECM即是采用此种方法。具体流程如图3—7所示。噪声能量估计图3—7舒适噪声生成流程图其中T．在算法里取26或者29，如果是前一百次取26，否则取29。T：的值取2“一1，L取值是‘211+1’／2",B取5，即以5个块为单位进行更新。Mid：l一研f】， 万方数据VolP电话中基于WebRTC的回声消除算法的开发b-实现第三章WebRTC中AECM算法实现其中jrfl是噪声的抑制增益。R是一个64点的在[0，359]上的均匀分布。Tcos和Tsin分别是在rn，，。1上360点的余弦和正弦函数。这是利用在[0，1]上的服从均匀分布的随机数经过一定的变换可以产生服从N(O，1)上的白色高斯随机数。其理论基础是随机信号分析的伪随机理论乜11。黄色框内为进行背景噪声能量估计的流程图，之外的部分为在此基础上依据背景噪声来模拟产生舒适噪声。背景噪声估计是以64点为一块进行频谱估计，首先将噪声估计值跟近端信号比较，如果比近端信号大，就将估计值过小计数器清零。然后将估计噪声跟门限T。比较，如果小于门限，则很缓慢减小估计值，减小比例为大于近端信号部分的]／T。；否则，会将估计过高计数器加一，如果计数器的数目超过B，即连续B个数据块，该点频谱都估计过高，且超过门限，就将噪声估计值直接减一。如果比近端信号小，处理原则与之类似。背景噪声估计好之后，会将其与一个高斯分布相乘，最后得到输出信号。3．3本章小结本章分为两个部分，WebRTC的架构和AEC算法原理。首先介绍了WebRTC的架构，然后介绍了WebRTC的各个功能模块，包括音频部分和视频部分。音频部分包括编码，均衡，回声消除和降噪。视频部分包括编码，抖动缓冲和图像提升等。以及音视频的网络传输。在介绍AEC算法原理是，首先给出了AEC的原理框图，并分析了各个模块的主要作用，然后给出了代码实现的主要流程，之后详细的分析了快速傅里叶变换，自适应系数更新，残余回声非线性处理和舒适噪声生成等四部分，并给出了详细的流程图。30 万方数据VolP电话中基于WebRTC的吲声消除算：法的开发’j实现第pq章测试。卜台搭建4．1软件平台搭建第四章测试平台搭建本文是研究嵌入式设备上的回声消除。所以本文选取当前在嵌入式设备上应用最为广泛的android㈦1操作系统作为软件平台。本文所选取的android版本是2．3．4。所使用的VolP应用程序是1inphone。linphone是基于sip协议栈的。由于AECM所工作的载体是linphone，所以本章会先对linphone的架构以及工作流程做一些介绍。4．1．1linphone架构本文所使用的linphone是从linphone开源网站上“踟下载的android平台的版本。首先给出linphone的架构图，如图4—1所示。图4一llinphone架构 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建linphone应用程序主要包括两部分，一部分是图形化的用户界面即1inphoneUI(UserInterface)。这一部分是由java代码编写的linphone．apk。另一部分是真正实现各种功能的liblinphone．SO动态库。linphone．apk在运行的时候会动态加载liblinphone．so。而1iblinphone．SO是由两部分编译出来的，即linphone—core和Ortp，mediastream2，以及eXosip等功能模块。这部分都是用C语言编写的。上层1inphoneUI要调用底层linphone—core中的函数的话是通过1inphone—jni来实现的。所谓jni即jave与native的interface。linphone—core是很重要的一层，起着承上启下的作用。Ortp主要是实现RTP协议的网络传输功能，即最终所有的报文都是通过这儿进行发送和接收的。mediastream2是实现linphone中音视频的播放采集。而eXosip是对osip再次封装，顾名思义它主要是实现sip协议的信令交互。4．1．2linphone运行流程上-d,节已经对1inphone的整个架构做了简单的介绍。本小节会对linphone的运行流程进行分析。因为AEC是在音频处理中起作用的，所以本文会对mediastream2的音频流程作详细分析。1．呼叫流程分析linphone的呼叫流程，如图4—2所示。 万方数据VoIP电话中基于WebRTC的吲声消除算法的开发‘j实现第叫章测试平台搭建图4—21inphone的呼叫流程其中空心箭头表示函数的调用关系，实心箭头表示流程走向。每个带颜色的块表示一个独立的代码块。当用户在界面上拨号后，首先Linphone—core—invite会被调用，该函数会解析sip的URL，并构造一个发送一个INVITE消息的请求。它同时会调用eXosipcallbuildinitialinvite，这个函数会创建最简单的INVITE请求。之后linphone—call_new—outgoing会被调用，这个函数是创建一个1inphone—call对象。之后linphone—set—sdp被调用，它会将构造好的SDP数据包打包进入到通信数据中。然后调用Linphone—core—init—media—stream来创建通话所需要的音频流和视频流，如果只是音频通话的话指只创建音频流。然后调用eXosip—call_send—initial—invite将已经构造好的INVITE信息发送。而它实现这一功能又会调用到三个函数，它们具体的功能如下：1)eXosip—call—init会创建化一个LinphoneCall对象，并对该对象进行基本的初始化。Linphone里每个通话过程中保持一个LinphoneCall对象。2)eXosiptransactioninit初始化一个transaction。该transaction的id是一个静态的递增值，在整个系统运行的过程中其值是唯一的。一个transaction的初始化过程中有三个最重要的动作：a)将系统初始化时创建的osip对象附给transaction。 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建b)初始化transaction的事件队列。C)根据状态机的类型将transaction加入到状态机中。3)osiptransactionaddevent会该函数将事件加入到transaction的事件队列中。Linphone的呼叫从这儿正式开始了，但是我们可以看到请求事件还没有发送。这个是由在系统初始化时的创建的eXosip—execute线程会不断的查询是否有数据需要处理。当它发现要状态机中有需要处理的数据的时候，它会调用在系统初始化时通过eXosip—set—callbacks函数注册的事件处理函数。这些注册函数处理完数据后会发送eXosip—event，从而linphone可以调用eXosip—event对应的相应的处理函数。处理函数会将数据发送给通话的另一方。2．响应流程分析1inphone的响应流程如图4—3所示。其中，各个箭头和颜色块的含义和图4—2一样：图4—3linphone响应流程当用户听到振铃音后在图形界面上点击接听键后会调用linphone—core—answer用于响应。该函数会调用linphone—core—accept—call，其完成的功能首先是停止响铃，然后发送一个0K的信息给呼叫方，接着初始化音视频，开始通话，具体每项功能由其调用的函数来实现，具体如下：1)eXosip—call_build—answer数会构建一个200的响应sip包； 万方数据VOIP电话中基于WcbRTC的回声消除算法的开发与实现第四章测试平台搭建2)linphonecoreinitmediastreams用于初始化AudioStream以及VideoStream：3)eXosipcallsendanswer将相应的事件加入到状态机，并等待处理；4)inphone．corestartmediastreams数取得linphone系统初始化时调用sound—config_read中初始化的声卡，并将音视频编解码所用到的filter串接起来，即完成音视频通话中媒体所需要的一起工作。由于本文主要分析AEC的效果，所以重点介绍一下音频部分，对视频部分的流程不做进一步描述。5)linphone—core—start_media_stream会调用audio—stream_start—now，而该函数只是对audo—stream_start—full的一个封装，具体工作由audo—stream_start—full来完成。6)audostreamstartfull主要目标是完成对AudioStream的初始化，设置该通话过程中要用的声卡读写、RTP数据发送／接收、编码、解码器的过程。由于这一过程比较复杂，下面单独给出一幅图来描述，如图4—4所示。其中各个符号的含义仍与前两幅图相同。 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建图4—4audiostream流程Audiostream的运行是由2个graph来完成的，一个完成接收，另一个完成发送。具体的实现步骤和每个函数的功能如下：1)audo—stream—start—full首先调用ms—filter—calImethod，这个函数会被调用多次，每次创建一个不同的filter。所谓filter是mediastream2自定义的一种数据结构。Filter的基本功能就是将输入的数据进行处理，然后放到输出队列中。ms—filter—call_method创建的filter包括audiostream一>soundread，audiostream一>soundwrite，audiostream一>rtpsend，audiostream一>rtprecv等。2)ms—filter_create—encoder会通过AudioStream结构体中的参数查找RTP会话中对应的payload，然后根据payload里面的mime(MultipurposeInternetMai1Extensions)类型创建编码器过滤器。创建的步骤是首先找到符36 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建合MSFILTERENCODER和mime的MSFiiterDese，然后通过ms—filter—new—from_desc绑定MSFIlter。3)msfiitercreatedecoder与msfiItercreateencoder类似，只是它是创建解码器而已。4)setsoundfilteparameter和setcodecsparameter是设置相关滤波器参数，诸如采样速率等。5)ms—fiiter_link是很重要的一个函数，它会将之前创建好的各个fiiter链接在一起，形成一个graph来完成发送音频数据和接收音频数据的功能。6)ms．tickernew会创建一个ticker，在一个音频对话过程中，linphone只维护一个ticker，用来管理两个graph，实现同步等。7)msticker．．attach用于将MSFilter与MSTicker进行绑定。在这里分别绑定了stream一>soundread和stream一>rtprecv。图4—4中黄色的部分即是完成音频通话最重要的两个graph。上面的一个用于接收，下面的一个用于发送。在解释音频的发送和接收流程之前，首先解释一下数据在各个fiiter之间是如何传递的。每个fiIter中都会有out和in的引脚对应该fiIter中队列的编号，mS—filter_link的时候会将f订ter的out和in引脚的参数传递进来，则上一个fiiter则获得数据后就会将其out引脚对应的队列里面的数据发到下一个fiiter的in引脚对应的队列里。在清楚了这一点之后就不能理解音频的发送和接收的流程了。音频的接收的过程：rtprecv会接收从网络过来的RTP数据包，然后传递给decoder做解码，解码后的数据又会传递给volrecv进行整形、降噪等处理。处理完的数据会传给AEC，AEC会进行保存，作为回声消除的远端参考信号。然后直接送给writerresampler进行重采样。重采样的数据就可以送给soundwriter通过audiofilinger或者直接操作声卡播放。音频的发送过程：soundread会通过audiofilinger或者直接操作声卡获取声卡采集的数据，然后将数据传递给readresampler进行重采样。重采样的数据会送到AEC里进行结合之前储存的远端参考信号做回声消除。经过消除掉回声的信号会传递给volsend做整形、降噪等，然后语音信号会传递给encoder进行编码，编码完成的信号即可以传递给rtpsend通过RTP协议发送出去了。4．1．3AEC算法在linphone中的实现从上一小节的分析中我们已经了解到要想在linphone中将AECM模块移植进来就要实现符合mediastream2中filter格式的ECFilter。正如上一小节所提到的，在新建一个filter对象的时候要传递它的描述，对于AECfiiter也不例 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建外。它的描述跟其他filter一样，实现mediastream2定义好的成员和成员函数，具体如下面所述：MSFiiterDescms—aec—desc=(．id=MS_AEC-ID，．name=”MSAEC”，．category=MS—FILTER—C}THER，．ninputs：2，．noutputs=2，．init=aec～init，．preprocess2aecpreprocesst．process2aec_process，．postprocess2aecpostprocess，．uninit=aec—uninit，．methods=aec_methods}：其中ID是在ms—filter．h中加的id，在新建一个AECfilter的时候便可以根据它的ID找到对应的描述。Inputs和outputs的数目是2在图4—4中的audiograph中已经体现出来了，AECfilter需要2个输入队列和2个输出队列。init，preprocess，process，postprocess，uninit是这个filter要实现的5个函数，分别完成初始化，预处理，处理，后处理，反初始化的工作。下面对这5个函数进行详细描述来阐述具体AECM算法是怎样在linphone中起作用的。aec—init是对参数进行初始化，包括没帧的大小，是否启用此算法，固定延时，AECM中所必须保存的参考数据等；aec_preproaess是完成aecm对象的创建，已经该结构体中所用到参数的初始化等；aec_process是完成对输入远端信号的保存，经过回声消除信号的输出，当然还好对图3—3中WebRtcAecm_Process函数的调用。对于aecfilter当中的四个队列本文是这么使用的：inputO队列中只是保存远端参考信号，而outputO队列是对inputO的拷贝，用来输出到下一个fiIter的队列中；inputl队列是存储近端信号，而outputl队列是用来输出经过回声消除处理后的信号。aec—postprocess用来清空所创建的缓存中的数据已经释放结构体对象所占用的空间；aec—uninit是实现文件关闭，空间释放，以及此fiIter对象的释放。至此，通过这样一个filter，AECM模块便被应用到了linphone中。 万方数据VolP电话中基于WebRTC的同声消除算法的开发与实现第四章测试平台搭建4．2硬件平台搭建DM6446是TI公司于2005年12月推出的高集成度芯片，业界称为达芬奇(DaVinci)数字多媒体片上系统。该芯片包括ARM(AdvancedRISCMachines)子系统、DSP(DigitalSignalProcessing)子系统、VPSS(VideoProcessSubSystem)视频处理子系统和系统控制模块；另外还有电源管理、外部存储接口、外围控制模块等部件。本文主要研究回声消除问题，所以重点介绍一下音频模块。4．2．1音频模块简介DM6446在声音的输入上支持麦克风和内置耳机两种输入方式。在芯片内部集成了模数转换和数模转换部件，并采用了先进的Sigma--delta过采样技术，可以在8K到96K的频率范围内提供16bit、20bit、24bit和32bit的采样输出，ADC(A／DConverter，模数转换器)和DAC(D／AConverter，数模转换器)的输出信噪比分别可以达到90dB和lOOdB，对高音质重放有极大的帮助。DM6446集成有音频数据流的双向McBSP(MultichannelBufferedSerialPort，多通道缓冲串行口)通道，通过设置采样频率、采样宽度、串行数据格式可以支持多种音频格式。DM6446通过12C总线对AIC23B的寄存器进行配置，利用12S格式进行声音数据的双向传输，利用可编程数字锁相环PLL(PhaseLockedLoop)为AIC23BCODEC(编译码器)提供时钟，并通过分频产生所需的采样时钟，本文所采用的时钟频率为8KHz。本文通过Linux系统下的ALSAAdvancedLinuxSoundArchitecture，高级Linux声音体系)驱动来实现对AIC23B的配置。4．2．2开发环境搭建随着计算机技术、大规模集成电路的发展，嵌入式设备的性能越来越高，软件功能越来越广，产品种类也日趋增多，移动电话、便携式多媒体、诸如智能手机平板电脑等智能终端之类的嵌入式设备几乎随处可见。但是，相比于PC机而言，嵌入式设备还是在性能有很大的局限性。因此，在嵌入式设备开发的时候，并不能使用嵌入式设备本身来编译代码生成可执行软件。而是需要在开发主机上建立一个交叉编译系统，通过交叉编译来为嵌入式设备生成可执行程序从而在设备上运行。在嵌入式目标平台没有操作系统的情况下，可以通过主机上安装的编译器如ADSI．2，CCS3．3等来编译生成嵌入式目标平台上的可执行程序，然后下 万方数据VOIP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建载到开发板上烧写执行。在目标平台移植了操作系统后，可以通过开发主机安装arm-1inux-gcc这一类编译器，通过编译器编译链接生成可以直接在目标平台操作系统下运行的程序，然后下载到开发板执行，并通过串口线连接开发板，在开发主机上安装minicom，putty等串口程序来输出程序执行时的打印信息。通过打印信息我们可以监测程序运行的状态，从而找到源代码的错误并修正。DM6446开发板的运行程序也是通过这样的流程来编译烧写到开发板上的。但是要详细了解DM6446开发板如何运行在4．1节中提到到软件平台编译出来的可执行程序，还需要了解DM6446的ARM处理器的启动流程。DM6446的ARM处理器有各种各样的启动方式，因为正常用到最多是从NANDFlash的启动，所以这里主要介绍从NANDFlash启动，一般要经过以下五步：1)RBL(ARMROOMBootLoader)2)UBL(UserBootLoader)3)U—Boot4)kernel5)android应用第一步中的RBL代码(ANROMBootLoader)在芯片出厂的时候就已经烧写到ROM(Read—OnlyMemory)当中，当开发板上电或者执行复位操作时，处理器就会执行该RBL代码。它的作用是将第二步中的BootLoader代码复制到ARM的内部RAM(randomaccessmemory)中执行。在第一次启动开发板时，板子上只有这部分RBL代码，在启动方式上需要选择从内存启动，等板子启动起来，可以通过串口中的ymodem协议将开发主机编译出来的BootLoader传送至开发板。然后执行RBL代码，将该BootLoader代码复制到开发板处理器的RAM中。第二步中的UBL(UserBootLoader)代码被烧录在NANDFlash从Blockl开始的连续5个存储块(Block)中。DM6446的ARM处理器只有16KB的内部RAM，而正如第一步中提到的BootLoader程序是由RBL复制到RAM中执行，故RBL只支持存储在NANDFlash中小于RAM大小的BootLoader程序，一般要求小于14KB。这部分UBL代码一般由开发者自己编写，它所实现的主要功能就是从NANDFlash中读取第三步中提到的U-Boot，然后把U-Boot复制到DDR2中执行。如第一步中提到的在第一次启动开发板之后，通过ymodem将BootLoader传送进来之后，仍然需要通过ymodem将U-Boot传送进来，当U-Boot启动之后，在U-Boot里执行命令将BootLoader和U～Boot烧写到NANDFlash中。第三步中的U-Boot是一个功能强大的BootLoder。除了实现硬件设备初始化外，还实现了读写DDR2、Flash、串口下载、以太网tftp协议下载、传递内 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建核参数以及命令行模式的用户交互界面等复杂的功能。它存储在NANDFlash中紧跟UBL的位置，由UBL将其复制到DDR2中执行。第四步中的操作系统内核镜像文件由在开发主机编译出来，然后通过U—Boot的tftp协议下载复制到DDR2中执行。第五步中的android应用也是由开发主机编译出来，本文所搭建的软件环境最终是将android系统所编译出来的系统加载运行所需要的文件都打包成一个压缩文件，由于文件比较大，需要通过nfs工具将编写出来的systemimagemount到开发板中，然后将该文件解压到开发板即可。至此系统就可以运行起来了。4．2．3ALSA驱动本文的实验平台是采用ALSA来播放和录制声音的。ALSA是为声卡提供驱动的Linux内核组件，以替代原先的OSS(OpenSoundSystem开放声音系统)。之所以可以替代OSS，因为相比于OSS来说ALSA具有很多优点。总体来讲，ALSA的优点有：·支持的声卡设备多样●内核驱动程序模块化●支持对称多处理(SMP，SymmetricalMulti—processing)和多线程·提供可以简化应用程序开发的应用开发函数库·兼容OSS，支持OSSAPI下面介绍一下ALSA的体系结构。总体来说ALSA系统包括7个子项目：1)提供内核驱动程序的alsa-driver驱动包，2)提供用户空间的函数库的alsa—fibs开发包。3)alsa-1ibplugins开发包插件4)用于控制声卡的应用程序包alsa—utils，如alsaconf、aplay、arecord等。5)工具箱alsa-tools6)alsa-firmware，提供支持特殊音频固件7)与OSS接兼容接口alsa—OSS．为更好的了解ALSA的驱动原理，下面给出ALSA体系结构图，如图4—5所示。 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建ALSA应用ALSA库图4—5ALSA体系结构图4—5的硬件即指声卡设备。从图中可以看到ALSA内核驱动和用户空间应用程序之间的关系。从图4—5中可以看到ALSA是以内核驱动程序的形式运行在Linux内核空间中的，我们都知道用户空间的应用程序想要访问内核空间的设备必须借助系统调用，当然访问声卡也不例外。具体的调用过程也都类似，即：首先使用open系统调用打开硬件，此系统调用会返回一个文件描述符，该文件描述符将作为随后操作的标识；然后用read系统调用读取设备上的数据，或者用write系统调用写入数据给设备，如果无法通过read或者write调用完成，则可以采用ioctl系统调用来实现：最后，使用close系统调用通知Linux内核关闭设备。一个典型的声音程序通常有类似下面的流程，如图4—6所示。 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第四章测试平台搭建图4—6ALSA声音程序流程示例图除了设置硬件参数，其他几步都可以通过上面的系统调用来完成。设置硬件参数是很重要的，因为参数设置不当将会导致音频设备无法正常工作。常用的硬件参数有样本长度、通道数、桢、采样率、周期、交错模式等。下面简略下面简略介绍一下各个参数的含义。样本长度(sample)：这个概念等同于PCM量化编码比特位数，是记录音频数据最基本的单位，常见的有8位和16位。在本文的平台中采用16位。通道数(channel)：该参数为1表示单声道，2则是立体声。立体声的音质会比较好。在本文的平台中采用单通道。桢(frame)：桢记录了一个声音单元，其长度为样本长度与通道数的乘积。采样率(rate)：每秒钟采样次数，该次数是针对桢而言。本文采用8000／s周期(period)：音频设备一次处理所需要的桢数，对于音频设备的数据访问以及音频数据的存储，都是以此为单位。本文采用80，即IOms交错模式(interleaved)：是一种音频数据的记录方式，在交错模式下，数据以连续桢的形式存放，即首先记录完桢l的左声道样本和右声道样本(假设为立体声格式)，再开始桢2的记录。而在非交错模式下，首先记录的是一个周期内所有桢的左声道样本，再记录右声道样本，数据是以连续通道的方式存储。不过多数情况下，我们只需要使用交错模式就可以了。 万方数据VOIP电话中基于W曲R1℃的回声消除算法的开发与实现第四章测试平台搭建4．3本章小结本章主要论述AEC算法如何在VOIP中运行起来，即如何搭建平台测试AEC算法的性能。本文选取了1inphone作为VOIP软件，DM6446作为硬件平台，在该硬件平台上运行android操作系统，然后将1inphone作为一个应用程序集成到android系统里。故本章首先阐述了linphone的架构和运行流程，其后详细描述了如何将AEC算法移植到linphone中。在介绍完软件平台后，介绍了硬件平台的搭建，首先阐述了DM6446的特点，重点介绍了其音频模块，然后介绍了嵌入式程序编译和系统启动的流程，最后介绍了本文声音部分所需要的ALSA驱动。 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第五章测试结果及分析在第四章本文详细描述了如何搭建测试所需要的软件和硬件平台。这一章主要就是在此基础上对AEC算法进行测试了。由于回声消除的应用场景比较复杂，无法对所有的回声情况进行详尽的测试，本文结合G．168所提出的客观指标，并结合实际应用情况设计了测试场景，在下一小节会进行详细阐述。5．1测试场景设计本章进行了3个场景的测试，包括只有远端讲话，双端同时讲话和只有近端讲话3种场景。具体描述如表5一l所示。表5一l测试用例描述～述测试场景测试目的测试预期效果测试窃慕描述＼1．远只有远端测试对回声消近端可以清晰端讲话通话者讲话除效果流畅地听到远端通话者的声音，远端通话者听不到自己的回声2．双远端和近测试在消除远双端都可以清端通话端通话者同时端回声的时候有没晰流畅地听到对方讲话有滤掉近端有效信的声音，且听不到自号己的回声3．近只有近端测试有没有损远端可以清晰端讲话通话者讲话伤近端信号流畅地听到对方的声音，且听不到自己的回声按照表5一l设计的测试场景，用第四章给出的方法编写出了集成了AEC算法的升级包烧写到两台DM6446设备中。建立语音通话之后，笔者和搭档主观感觉效果还不错。但是考虑到主观感受没哟说服力，笔者抓取了近端输入数据，远端输入数据和经过回声消除处理后的输出数据，并用cooledit软件打开这些PCM45 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第五章测试结果及分析数据查看波形，以证明该AEC算法的效果。本文将在下一小节给出具体波形图，并进行分析得出本文结论。5．2测试结果分析5．2．1远端讲话话测试结果分析首先给出测试场景1远端讲话的远端输入信号，近端输入信号和AEC处理后的输出信号的波形图，如图5—1，图5—2，图5—3所示。图5—1远端通话时远端输入信号波形图图5—2远端通话时近端输入信号波形图 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第五章测试结果及分析图5—3远端通话时经AEC处理后输出信号波形图图5—1表示远端语音信号的波形图，图5-2表示近端语音信号的波形图，图5—3表示经过AEC处理后的输出语音信号的波形图。这些波形图的获得是在硬件设备中通话过程中保存下来PCM格式的语音信号，然后用cooledit软件打开，下文中所有的波形图也是如此获得。由图5—1，图5—2，图5—3可以看出，远端信号到达近端由近端扬声器播放后经过反射或者直接被麦克风采集后行程回声信号成为近端输入，该近端输入相比于远端原始信号已经衰落很多，但是如果不经处理直接传送到远方，远端肯定可以听到自己的回声。而该信号经过AEC处理后的输出信号即图5—3，相比于图5—2的原始输入信号基本已经全部消除掉了，除了个别几个点。可见在只有远端通话的情景下AEC算法可以很好的工作。5．2．2双端通话测试结果分析下面给出在双端讲话情形下的测试结果。远端参考语音信号，近端语音信号和经过AEC处理后的语音信号的波形图如图5—4，图5—5，图5-6所示。因为双端通话情形下自适应滤波器有可能会逐渐不能收敛，故相比于只有远端通话的情形抓取数据要多，本次测试抓取双端通话数据时常是70s，而远端通话清行下抓取的数据只有30s。47 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第五章测试结果及分析图5—4双端讲话时远端输入信号波形图图5—5双端讲话时近端输入信号波形图 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第五章测试结果及分析图5—6双端讲话时经AEC处理后输出信号波形图图5—4表示远端语音信号的波形图，图5-5表示近端语音信号的波形图，图5-6表示经过AEC处理后的输出语音信号的波形图。从图5—4，图5—5可以看出，近端输入信号即图5-5基本与远端输入信号即图5～4关系不大，这是由于回声信号能量相比于原始信号要小很多。图5—1，图5—2可以证明这一点。从图5—5，图5-6可以看出，近端输入信号与经AEC处理后的输出信号即图5—6基本一致，但是由于采集到的信号幅度比较大，对比不是很明显，可能肉眼不能得到的结论不可靠，故将三幅图放到一起进行对比，如图5—7所示。图5—7远端输入信号近端输入信号和输出信号波形对比图49 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第五章测试结果及分析在图5—7中，正如其左上角所标注的，最上面的那副表示远端输入信号，中I'BJ的表示近端输入信号，而最下面的则表示输出信号。我们可以看到输出信号和输入信号并不是完全一致的，而这些削弱的地方恰恰是远端信号存在的地方，在进行这点对比的时候因为本问给出的远端信号是AEC模块中直接接收到的对端发过来还没有经本地扬声器播放的信号，故要注意远端信号和近端信号在横轴即时间轴上不是完全对齐的，因为远端信号相比于近端输入信号存储的要早，由于近端信号的输入采集以及本身远端信号从AEC模块到达扬声器播放再到变成回声被麦克风采集之间有时延，所以近端信号要比远端信号要延迟一点。经过以上分析可以表明在双端通话时AEC算法也可以很好的工作。但是由于在第三章中提到的该AEC算法没有做很完善的双端检测，在双端持续大幅度的讲话下，白适应滤波器将近端真实语音输入也当做回声一起处理导致在本地会听到对端的语音逐渐被抑制。由于这一点一来在波形图上不是那么明显，而来出现这种现象时间较长，变化又比较平滑故这里没有给出波形图证明。5．2．3近端讲话测试结果分析上面给出了远端通话和双端通话的测试结果，这个结果其实对于证明回身消除功能由多强大没有太大意义，主要是证明对近端语音信号，该回声消除器不会错误的扭曲。由于这是远端信号不存在，所以只给出近端语音信号波形图和经AEC处理后的输出信号波形图，如图5-8，图5—9所示。图5—8近端讲话时输入信号波形图 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第五章测试结果及分析图5—9近端讲话时经AEC处理后的输出信号波形图图5—8表示近端语音信号波形图，图5—9表示经AEC处理后的输出语音信号波形图。从图5—8，图5—9可以看到近端讲话时近端语音信号波形和经过AEC模块处理后的输出语音信号的波形基本是完全一致的。为了更清楚的对比，下面给出这两幅图插入到多轨中的对比图，如图5—10所示。图5一10近端输入信号和输出信号波形图在图5一10中，上面的一幅表示近端输入语音信号波形图，下面的是经过AEC模块处理后的输出语音信号波形图。通过图5-10我们可以看到近端讲话时近端 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第五章测试结果及分析语音信号波形和经过AEC模块处理后的输出语音信号的波形基本是完全一致的，即AEC算法不会对近端语音判断失误而进行回声消除误处理进而导致输出的语音信号与输入语音信号相比失真。5．3本章小结本章在前面章节的基础上，为了验证AEC算法的效果，设计了测试场景，主要包括远端讲话，双端讲话和只有近端讲话。一方面笔者和搭档对测试的效果进行了聆听，主观感受该AEC算法的回声消除效果还是非常不错的。为了给出切实有效的证明，本文又抓取了在三种场景下近端输入信号，远端输入信号和经过AEC模块处理之后输出信号的语音数据，然后经过cooledit软件打开观看波形图。经过波信图对比发现，远端通话的情景下AEC算法可以很好的工作，语音信号绝大部分可以被消掉，只是偶尔会有几个点有极弱的回声信号输出。在双端通话时AEC算法也可以很好的工作，但是由于该AEC算法没有做很完善的双端检测，在双端持续大幅度的讲话下，自适应滤波器将近端真实语音输入也当做回声一起处理导致在本地会听到对端的语音逐渐被抑制。近端讲话时近端语音信号波形和经过AEC模块处理后的输出语音信号的波形基本是完全一致的。总体来说该AEC算法性能还是很不错的。 万方数据VoIP电话中基于WebRTC的回声消除算法的开发与实现第六章结论本文研究了WebRTC中开源的AEC回声消除算法在VOIP中如何应用以及其回声消除效果。其中本文选择的VOIP应用程序是基于开源VOIP软件linphone的，而VOIP所应用的平台，本文选择了当前应用非常广泛的android操作系统，而硬件平台本文选择了TI公司的DM6446。在软件上虽然本文选择的是开源的android系统，但是AECM算法本身并没有操作系统的局限性，只要能在其他平台上可以成功移植进来，该算法也能发挥效果。在硬件上虽然本文选择的是TI公司的特定一款产品，但是基于嵌入式终端的相似性，本文的研究结论对于诸如智能手机平板电脑等所有的嵌入式设备都是有通用性的。下面笔者就给出本文的研究结论。6．1本文研究结论本文在将AEC算法移植到1inphone开源软件中，经过参数的修改适配和1inphone中AECfilter的按照mediastream2的filter规范的编写，终于使AEc算法在1inphone中可以成功运行起来。笔者将编译好的程序下载到开发板上运行起来之后根据设计的测试场景笔者和搭档进行了测试。笔者在linphone程序中加上了打开关闭AEC算法的开关，在聆听对比中，可以很明显的发现，在AEC算法没有打开时可以很清楚的听到自己的回声，且不止一次，即在听到第一次回声之后又听到第二次回声在第二次回声后又有第三次且声音越来越小。而在打开AEC算法之后声音效果即刻转好，基本上听不到回声。本文分远端讲话，双端讲话和只有近端讲话三个场景进行了测试，并且抓取了测试的近端输入语音信号，远端输入语音信号和经AEC模块处理后的输出语音信号的波形图。在对波形图分析之后并结合聆听对比语音效果，得出结论如下：1)远端通话的情景下AEC算法可以很好的工作，语音信号绝大部分可以被消掉，只是偶尔会有几个点有极弱的回声信号输出。2)双端通话时AEC算法也可以很好的工作，但是由于该AEC算法没有做很完善的双端检测，在双端持续大幅度的讲话下，自适应滤波器将近端真实语音输入也当做回声一起处理导致在本地会听到对端的语音逐渐被抑制。3)近端讲话时近端语音信号波形和经过AEC模块处理后的输出语音信号的波形基本是完全一致的。总体来说笔者和笔者的测试搭档都认为该AEC算法性能还是很不错的。 万方数据VolP电话中基于WebRTC的回声消除算法的开发与实现第六章结论6．2不足和展望正如在上一小节总结结论中所提到的由于该AEC算法没有做很完善的双端检测，在双端持续大幅度的讲话下，自适应滤波器将近端真实语音输入也当做回声一起处理导致在本地会听到对端的语音逐渐被抑制。所以对该AEC算法进行完善的双端检测是该算法要提升的。同时，偶尔也会听到回声，笔者分析这应该是由于该算法的非线性处理即残余回声非线性消除上算法设计的不够好。同时还有由于该算法没有实现实时的本端的静音检测，只是对远端信号做了语音活动性检测，以用来决定是否需要滤波。然后根据滤波后的误差大小去推断是否有本地语音，这种判决误差是很大的。不仅如此，判决的结果也没有实现实时反馈给AEC控制器，以使其可以控制舒适噪声发生器。这样造成的结果就是虽然通话中有很长的静默期，但语音编码速率并没有降低。这一点虽然不影响话音质量，但是对带宽造成了一些浪费。由于本文时间有限，使得笔者还没能将以上这些瑕疵改善的完美，这部分工作真是笔者下一步要努力的方向。在总体Jl生能上进行评价该算法效果还是不错的，如果跟常用的VOIP软件相对比的话该算法在性能上跟QQ语音聊天差不多。加之该算法是开源的，这必将会促进VOIP更广泛的应用。 万方数据参考文献[1]-VOIP基本概念：回声消除技术[EB／0L／]．http：／／刚哪．5lcto．com／art／200512／13682．htm，2005-12—08[2]，百度百科voip[EBIOLI]．http：／／baike．baidu．com／view／1475．htm[3]．苗欣．2012年VoIP市场收入有望增长至6．537亿[EB／OL／]．http：／／嗍，cI14．net／news．／43／a469312．html，2009-12-21[4]．IETFRFC3261，SIP：SessionInitimProtocol，2002[5]．谢希仁．计算机网络[M]．北京：电子工业出版社，2010：17，23[6]．ITU—TRecommendationG．723．1．DualRateSpeechCoderforMuItimediaCommunicationsTransmittingat5．3and6，3kbit／s．【7]．ITU—TRecommendationG．168．DigitalNetworkEchoCancellers．[8]．StevenL，Gay，JaeobBenesty．AcousticSignalProeessingforTelecommunication[M]．KluwerAeademicPublishe，BostonIlardbound，2000[9]．StevenL．Gay，JaeobBenesty，DennisR．Morgan，etc．AdvancesinNetworkandAcousticEchoCancellation[M]．Springer，Berlin，2001[10]．H．K．Jung，N．5．Kim，T．Kim．AnewDouble—TalkDetectorUsingEchoPathEstimation．IEEETransactiononAcousticandSpeeehSignalProeessing，2002：1897，1900[11]．耿洁，VOIP中回声消除的分析和研究[D]，昆明理工大学，2007[12]．李挥，林茫茫，胡海军等．VoIP回声消除器设计及算法研究[J]，电子学报，2007，35(9)：1774，1778[13]．刘碉莹．基于NLMS回声消除算法的研究和改进[D]．西安电子科技大学，2006：13，30[14]．R．Martin，J．Altenhoner．CoupledAdaptiveFiltersforAcousticEchoControlandNoiseReduction[C]．Proc．Int．ConfAcoustics，Speeeh，SignalProeessing，1995：3043，3046[15]．张珍．VoIP自适应滤波算法的研究[D]．燕山大学，2009：12，13[16]．黄亮。基于DM6446嵌入式平台的语音增强算法实现与优化[D]。哈尔滨工业大学，2010：11，655 万方数据VOIP电话中基于WEBRTC的回声消除算法研究参考文献[17]．领先的无线电话供应商集成GIPSNetEQ技术[EB／OL／]．http：／／www．dlnet．com／VoIP／cnews／29239．html．2010—08—06[18]．http：／／www．1inphone．org／[19]．温和．新型窗函数及改进FFT谐波分析方法及应用研究[D]．湖南大学，2009：19，32[20]．张鹏．基于ARM的嵌入式VoIP终端设计及硬件实现[D]．上海交通大学，2008：48，49[21]．常建平，李海林．随机信号分析[M]．北京：科学出版社，2006：21，97[22]．曾光，侯嘉．android系统通话中回声消除的实现[J]．通信技术，201l，11(44)：41，43