转载

Android IOS WebRTC 音视频开发总结（二九）

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%以上，那可是质的飞跃啊。盼望你能回复，一起探讨一下这个问题怎么解决，谢谢了。 "

------------------------------------------------以下是我的回复:

" 您好,您的问题描述得很详细,分析得也很准确,说明您在这方面确实颇有研究.

回到android音频效果较差的的问题,先抛开手机硬件设计上的缺陷不谈,主要还是跟android设备种类繁多有关,所以webrtc里面对某些参数取的都是经验值,这样就造成不同手机效果大不一样, 所以适配这块是一个很大的工作, 所以最好的做法就是针对每种设备进行具体的适配,计算出具体的数值, 这样会比较准确, 不过这个投入是很大的.

你目前只用webrtcdemo测试吗? 你反馈的这个我没有弄过,因为一般用WebRTCDemo的都会重写传输模块, 另外附件发了个apk给你测试, 你可以用他和webrtcdemo比较下, 他们两者主要差别就是传输模块不一样. 另外这个问题我也问下我朋友吧.

测试APK详见附件, 后面略...... "

------------------------------------------------后面是陆陆续续的邮件交流,总结如下:

"对方后面用doubango里面的采集模块替换掉了webrtc里面的采集模块,测试发现采集和播放都很流畅, 用我提供的apk进行测试也很流畅,我们只能推测确实跟传输机制有关,但传输为什么会影响到音质的流畅性我们没搞懂,而且webrtc的采集和播放用到了很多的多线程,锁,看起来是很复杂,也很难维护.

当然也聊聊一些创业和工作相关的事情,因为跟这个主题关系不大,所以就不列出来了."

正文到此结束