Android上的音质一直被大家所困扰和诟病,这里面有很多原因,
下面是最近一位前UC同行发邮件跟我交流的一些记录,供参考,支持原创,文章来自博客园RTC.Blacker,转载请说明出处.
以下文字来自邮件,为便于阅读和理解,略有整理:
"Blacker,您好,本人一直从事音视频算法的处理与研究，包括H264视频，语音抑制，回音消除，噪音处理等分支。最近已经转向webrtc了，对webrtc也算是相对熟悉了。不过我在利用webrtc模块来开发时，遇到了一个音频采集的问题。不知道你是否遇到了，你们是否有相关的处理方法呢。
webrtc在pc和ios手机端，效果可以说是非常的好，但是在android手机端，效果就不怎么样了，语音断断续续的，效果很差，造成这个的其中一个因素就是AECM和AGC，噪音消除等这些模块造成的，我也仔细研究过这些算法的底层罗辑，发现下面的算法很多地方的初始值就是取一个经验值，这些值的大小影响最终效果，难怪苹果和ｐｃ设备的效果那么好，因为这些经验值很可能就是针对pc和苹果手机的。由于android手机设备种类繁多，所以不同的设备喇叭和麦克风不同导致效果差异太大。
当然这些我还可以修改底层的语音算法来优化，但是android端，有一个问题我始终没有头绪，就是音频部分的采集问题。基本上所有android手机，采集出来的音频数据就是不完整的，偶尔断断续续，加上后续音频的处理，经过处理后的效果就更差了。底层的音频采集，用了opensles来实现，当然他还提供了回调上层java来实现采集的模块，用一个开关WEBRTC_ANDROID_OPENSLES就可以打开,这些底层采集出来的语音都是有问题的。
用webrtc自带的webrtcdemo就可以测试出来，特别是关掉视频后，只开音频的话，问题更明显.采集部分的代码我也看过，里面有一个缓冲大小设置，这个调大后也是作用不大的。当然我也写单独的demo来测试，如果我不调用StartReceive和StartPlayout，而只是调用StartSend，那个采集出来的音频就是非常完整的，效果也非常好的，前两者只是开启了接收监听和播放线程，它和startsend开启的采集线程根本就是毫不相关的，为什么就相互影响了呢。
所以我有时候怀疑webrtc的架构是不是有问题呢?
这个问题一直都没有头绪，你在webrtc接触比我久，经验比我丰富很多，接触的牛人也多得多，我想咨询一下你们是怎么处理底层的声音采集问题呢，只要把这个问题解决了，android手机端的音频效果一定会提高50%以上，那可是质的飞跃啊。盼望你能回复，一起探讨一下这个问题怎么解决，谢谢了。 "
------------------------------------------------以下是我的回复:
"您好,您的问题描述得很详细,分析也很准确,说明您在这方面确实颇有研究.
