Android IOS WebRTC 音视频开发总结(二九)-- 安卓噪声消除交流

时间:2024-01-10 22:23:38

Android上的音质一直被大家所困扰和诟病,这里面有很多原因,

下面是最近一位前UC同行发邮件跟我交流的一些记录,供参考,支持原创,文章来自博客园RTC.Blacker,转载请说明出处.

以下文字来自邮件,为便于阅读和理解,略有整理:

  "Blacker,您好,本人一直从事音视频算法的处理与研究,包括H264视频,语音抑制,回音消除,噪音处理等分支。最近已经转向webrtc了,对webrtc也算是相对熟悉了。不过我在利用webrtc模块来开发时,遇到了一个音频采集的问题。不知道你是否遇到了,你们是否有相关的处理方法呢。

  webrtc在pc和ios手机端,效果可以说是非常的好,但是在android手机端,效果就不怎么样了,语音断断续续的,效果很差,造成这个的其中一个因素就是AECM和AGC,噪音消除等这些模块造成的,我也仔细研究过这些算法的底层罗辑,发现下面的算法很多地方的初始值就是取一个经验值,这些值的大小影响最终效果,难怪苹果和pc设备的效果那么好,因为这些经验值很可能就是针对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的采集和播放用到了很多的多线程,锁,看起来是很复杂,也很难维护.
        当然也聊聊一些创业和工作相关的事情,因为跟这个主题关系不大,所以就不列出来了."