基于Speex的音频调试实验（NS / AGC / AEC）
1. NS（噪声抑制）功能调试
使用全向Mic进行实验 :
波形图（不加去噪功能）：
波形图（加去噪功能）：
从波形中可以看出，去噪效果较为明显。Speex的降噪功能，对于人声有噪声抑制效果，但偶尔会有“噼噼”声，而对于音乐播放 “噼噼”的声音出现频率较高；建议播放音乐时关闭此降噪功能。
噪声消除模块需设置一个参数，即噪声抑制阈值（默认为-25dB），此值可控制噪声削弱强度。即噪声抑制阈值越小，噪声去除效果越好，但同时正常语音失真度也越大。另外，通过实验验证，不同噪声抑制阈值的设置与上述的”噼噼”现象无关。
“噼噼”声原因分析：
Speex降噪算法采用一种基于MMSE短时谱幅度估计的语音增强算法，即STSA-MMSE. 该算法利用人耳对语音相位变换不敏感的特性，估算得到短时幅度谱后，利用带噪语音相位信息，合成增强语音。出现“噼噼”声可能是估算短时幅度谱准确度不足导致的，另外由于Speex是针对语音信号开发的，因此对音乐播放适应性较差。
使用指向型Mic进行实验 :
波形图（不加去噪功能）：
波形图（加去噪功能）：
从波形中可看出，去噪效果较为明显。Speex的降噪功能，无论对于人声还是对于音乐播放均有噪声抑制效果，且未出现”噼噼”现象。可见mic的选型对去噪效果影响较大。
2. AGC（自动增益控制）功能调试
AGC在有人说话或播放音乐的情况下，效果较好；而在无人声说话或音乐播放的情况下会增益噪声，使噪声音量增大。
AGC开启之前波形图（和Mic同样距离念“9”时波形图）：
AGC开启之后波形图（和Mic同样距离念“9”时波形图）：
AGC开启之前波形图（环境噪声）：
AGC开启之后波形图（环境噪声）：
AGC算法共涉及以下4个参数设置：
- nAGC_Level ：取值范围为1 — 32768，值越大则音量越大
- nAGC_Inc ：前一帧到下一帧音频的最大增幅步长，其计算公式为：max_increase_step = exp(0.11513f * nAGC_Inc *frame_size / sampling_rate)，式中frame_size为帧长，sampling_rate为采样率
- nAGC _Dec ：前一帧到下一帧音频的最大减幅步长，其计算公式为：max_decrease_step = exp(0.11513f * nAGC_Dec *frame_size / sampling_rate)，式中frame_size为帧长，sampling_rate为采样率
- nAGC_MaxGain ：max_gain = exp(0.11513f * (nAGC_MaxGain)，音量增益
上述四个参数中，nAGC_Level和nAGC_MaxGain用于控制音量大小，nAGC_Inc和nAGC_Dec设置大于0时，易产生啸叫，正常的参数设置通常是nAGC_Inc设置为正值，nAGC_Dec设置为负值。
总的来说，Speex的AGC算法模型过于简单，在有人声激励的情况，表现比较好。能快速增益到合适的音量，缺点是当一段时间没有被正确的信号激励之后，会出现过多地增益背景噪声的问题，且因为增益不稳定，变化速度比较快，会不断地出现忽大忽小的背景噪声的情况。不同mic类型AGC功能的效果也不同，全向型mic容易产生啸叫，而鹅颈mic的AGC效果稍好。
Speex的AGC算法总的效果不尽如人意，不建议使用。
另外，AGC的开启与啸叫的产生关系较大，当AGC开启时，即使mic获取到很微弱的信号也可以通过AGC算法放的很大，这等同于将mic的灵敏度提升，容易产生啸叫，因此为防止啸叫需掌握好参数设置的度。
3. AEC（回声抑制）功能调试
使用全向Mic进行实验 ：
经调试发现，基于Speex的AEC算法有一定效果，但效果并不显著。这一调试结果并不意外，基于Speex的AEC算法在实时语音通信等非线性场景下，回声抑制效果并不是十分好。
使用指向型Mic进行实验 ：
在指向型Mic 条件下，基于Speex的aec算法效果比全向型mic的处理效果好，但参数设置需仔细调试，且参数一经确定之后，不能移动mic位置或音响位置，否则需重新调试。另外，网络的不稳定性同样会导致回声抑制效果不稳定。除此之外，Speex的回声抑制需几秒钟的学习收敛过程，因此一开始10几秒钟回声抑制效果不明显，之后回声抑制效果会逐渐显现。
4. 为什么大部分的回声消除算法都是基于DSP实现的，而很少基于Windows电脑实现？
实时性与高效性，DSP芯片资源有限而回声消除算法所需资源较大。以视频会议系统，大规模的会议室可以产生超过512ms的回音，要消除这么长延时的回音，即使按照8k赫兹采样率计算，自适应滤波器W(n)的长度都会达到4096个点，这样一方面需要非常大的存储空间来存储W(n)，另一方面，W(n)的更新需要的计算量也是成倍增长，同时，W(n)的收敛难度也在加大，传统自适应滤波器的效率很难保证。对于电信设备中的应用，虽然回声消除不需要这么长的延时，但是在交换机等设备中，成本和效率就是生命，所有的处理算法都是按路或按线计算的，对算法的优化效率提出了无止境的要求。相对而言，只有像车载免提这种应用对效率要求不那么高，因为车内空间小，回音延时有限，又不要求多路应用。
目前基于DSP的回声消除算法已比较成熟，市场上也有一批专门的算法/芯片公司的能够对外提供已经优化好的基于DSP的软件回声消除模块：如俄罗斯Spririt DSP、加拿大Octastic Semiconductor、瑞典GIPS、国内科莱特斯科技Conatus Technologies以及美国Adaptive Digital、和GAO Research、英国CSR等等，另外还有美国Fortemedia、Acoustic Technologies和日本OKI等可以提供专用的回声消除DSP芯片。
回声消除技术最新的应用领域是基于Windows平台的各种VoIP应用，比如软件视频会议，VoIP软件电话等。当回声消除算法应用到Windows平台，相对于传统的DSP平台，既带来优势，也带来了新的难点。高效性在Windows平台已经不是问题，现在的pc机，拥有丰富的CPU资源和海量的内存资源，再复杂的回声消除算法都可以运行自如。但是，新增加的麻烦比带来的好处要多。
首先，Windows平台是一个非实时的平台，音频的采集和播放对回声消除算法而言，也是非实时的。和DSP平台不一样，DSP平台可以直接控制AD/DA芯片的采集播放，获得实时的音频流（不存在同步问题），但是Windows平台下，应用程序很难在底层直接控制声卡的采集播放，获得的是非实时的音频流，从而带来了采集和播放音频流的同步问题。
实际应用时，传给回声消除算法的两个声音信号（采集的回音信号ne和播放的参考信号fe），必须同步得非常的好。即，本地接收远端语音后，要把这些语音数据传给回声消除算法做参考，这是算法需要的一个输入信号；然后再传给声卡，声卡放出来后经回音路径，这时，本地再采集，然后传给回声消除算法，这是算法需要的另一个输入信号。这里的同步是指：两个信号虽然存在延时，但这个延时必须固定，在时序上要保持连贯，不能一个信号多来几个帧，另外一个信号少来几个帧。如果传给回声消除算法的两个信号同步得不好，即两个信号发生帧错位，就没有办法进行消除了。因为这时系统会变成非因果系统，比如期望信号收到了，参考信号还没来，时间上都没有因果关系，肯定是无法消除的。
实际情况，在一般的VoIP软件中，接收对方语音（远端语音）并传到声卡播放是在一个线程中进行的，而采集本地语音（近端语音）并传送到对方在另一个线程中进行。声学回声消除（AEC）算法在对近端语音进行回声消除的同时，还需要播放线程中的数据作为参考。而要同步这两个线程中的数据是非常重要的，因为稍不同步，声学回声消除算法中的自适应滤波器就会发散，不但消除不了回音，还会破坏原始采集到的声音，使声音难以分辨。
另外，pc机器的声卡种类繁多，各种各样的声卡特性进一步加剧了同步问题的复杂性。所以，同步和声卡等问题对回声消除算法的内部特性提出了更多苛刻的要求。
从上面分析来看，由于Windows平台的非实时性，基于Windows平台的回声消除技术比DSP平台要难得多。在PC平台语音通讯领域，目前公认音质做得比较好的国外软件是Skype，记得几年前Skype一直是在用瑞典一家叫GIPS(Global IP Sound)公司的语音引擎技术。GIPS是最早介入PC平台语音通讯领域的厂商之一，在该领域具有一定的权威性，其主要优势表现在对IP网络的延时、抖动和丢包等处理较好，基于Windows平台的回音消除也做得不错，不过最近的新版本Skype上已经看不到GIPS的标志了，据说是因为Skype自己研发了一套新的更好的语音引擎的缘故。 目前大家接触最多的采用了GIPS语音引擎技术的通讯软件就是腾讯QQ了，其超级语音的效果普遍评价都还不错。另外微软经过多年的研发，其最新版本的MSN语音特别是回音消除效果终于有了质的提升，目前网上评价也还不错。另外还有一些专业厂商也对外提供包含回音消除功能的语音引擎，如俄罗斯的Spirit DSP、美国的GH Innovation和国内的科莱特斯科技（Conatus Technologies）以及赛声科技（Soft Acoustic）等等。
综合以上分析，
基于DSP的回声消除技术：芯片资源较小，实时性较高，易于实现近端语音信号和远端参考信号的同步；
基于Windows的回声消除技术：资源相对宽裕，能够轻松运行音频处理算法，但实时性不足，很难实现近端信号和远端参考信号的同步，导致很难实现回声消除的功能。