提升 RTC 音频体验 - 从搞懂硬件开始

简介: 本文字数:2143 字 阅读完需:约 7 分钟

前言

RTC(实时音视频通信)技术的快速发展,助力了直播、短视频等互动娱乐形式的普及;在全球疫情持续蔓延的态势下,云会议需求呈现爆发式增长,进一步推动了 RTC 行业的快速发展。为了给客户提供稳定可靠的服务,网络系统方面需要不断提升频道连通率,降低会议过程中的断流率,增强抗弱网能力;视频方面需要提升视频清晰度,降低视频卡顿率等,音频方面在追求端到端 MOS 的同时,也要重点关注音频 3A 算法的效果,这些都是各厂家必须修炼的 “内功”,也是最终沉淀下来的核心竞争力。本文将重点阐述硬件设备采集的音频质量对 RTC 端到端音频体验的重要性。

采集质量不佳,会有什么影响?

在 RTC 架构中,端到端的音频信号处理流程大致如下图,上行分别经过了音频信号的采集,音频 3A(AEC: 回声消除、ANS: 自适应降噪和 AGC: 自动增益控制)和编码;下行分别经过丢包恢复,解码,混音和播放。

image.png
端到端的音频信号处理流程

不难看出,音频信号经过模数转换,再经过设备集成的音频信号处理芯片,最后才传递给 RTC SDK。由于硬件厂商的不同,音频采集解决方案参差不齐,因此采集到的音频质量的好坏直接影响着 3A 算法拿到的生产资料的可用性,同时也决定这最终用户接收到音频信号质量的上限。根据实际工作中遇到的音频问题,因为设备采集引起的问题基本可以归纳为如下几类:

image.png

举几个例子:

(1)采集异常

采集异常主要体现在频谱 “模糊”,严重的会导致无法听懂语义,影响正常交流。如下语谱图。
image.png

另外,采集异常后,播放的信号被麦克风采集后也会表现出异常,从而引起严重的非线性失真,影响回声消除效果,如下图。
image.png

(2) 采集抖动

常见的就是采集丢数据,听感上会听到有很多高频噪点(下图为上图中噪点放大后的局部图),严重的会影响 AEC 算法中对延时估计准确性和远近端非因果问题,严重的会导致漏回声。
image.png

image.png

(3)爆音和音量小问题

采集爆音问题主要发生在 PC,也是 PC 端设备最应该避免的问题,影响较大,除了截顶导致的频谱失真之外,严重的非线性失真会影响回声消除效果。爆音问题需要 AGC 算法通过自适应调节 PC 端模拟增益以及麦克风加强解决。
image.png

(4)频谱缺失

频谱缺失主要是硬件回调的音频采样率与实际的频谱分布不一致,即使编码器给到很高的编码码率,听感上也没有高音质的效果,如下图,采集信号采样率为 48kHz,但是频谱上限却只有 8k。
image.png

改善采集音质,硬件层面我们能做什么?

具备 RTC 能力的硬件设备早已渗透我们生活的方方面面,常见的如移动端手机和 PC,现在甚至连儿童电话手表,天猫精灵以及各种高端的指纹密码锁等设备都支持了 RTC。然而,设备的多样性直接决定这采集能力的差异性,抛开声学元器件设计差异这一因素,就 Android 端而言,芯片和软件系统的差异使得同一品牌的手机,也没办法用同一种配置适配所有型号的手机。

另外,现在绝大多数的移动端设备都自带硬件音频信号处理(后称硬件 3A)能力,不同芯片效果方面也是千差万别的同时,更严重的是经过硬件处理的音频信号频谱往往会有缺失,如开启硬件 3A 后回调到 RTC SDK 的音频信号频谱上限仅支持到 8k,相当于 16kHz 采样的音频信号,尤其在娱乐方面根本无法满足我们对高音质的追求。因此,做好硬件层的适配工作,是保障 RTC 高质量音频体验的基础。

Android 端

(1)需要搞清楚 javaaudioclass 和 opensles 这两种模式的差异,以及各自需要适配的参数,掌握关闭硬件 3A 的配置。

(2)采集抖动或音频音量异常,可以试试更改请求的采样率,通常设置的 48k 采样不会适用于所有的 android 设备。

Windows 端

(1)当前很多 Windows 设备会在屏幕顶端内置麦克风阵列,提供音频增强功能,开启方式如下图。这个功能默认屏幕正前方夹角区域为拾音区域,通过麦克风阵列技术可以有效的增强拾音区域内发言人语音,“隔离” 拾音区域以外的 “噪声”,其主要的弊端就在于开启此功能后仅支持 8k 频谱,且各厂家增强算法存在差异,效果也参差不齐。因此,软件需要具备能够 bypass 硬件自带音频增强功能的能力,为高音质做保障。

image.png
Windows 设备自带的双麦阵列(图片来源于网络)

image.png
音频设置中的增强功能开关

image.png
开启音频增强后,带来的频谱缺失

(2)音量方面,PC 端设备都支持模拟增益调节,大多数带有阵列的 Windows 设备都有额外的麦克风加强(如下图)。软件算法层面(3A 中的 AGC)需要具备自适应调节他们的能力,保障音频采集音量的平稳以控制采集底噪水平。初值设置或自适应调节不当都会导致音量小和爆音等问题,严重的会影响回声消除和降噪的效果,带来影响可用性的风险。

image.png
模拟增益与麦克风加强

苹果设备

(1)ios 端适配工作较少,需要熟悉关闭硬件 3A 的配置,因为 ios 设备自带的硬件 3A 频谱也只能支持到 10k-12k。

(2)Mac 笔记本设备比较简单,仅提供了模拟增益调节。但是有一点需要注意,RTC 在支持双声道播放时,由于麦克风会与某个扬声器在同一侧,导致播放音频时附近的麦克风采集爆音问题,一般只能优化软件 AEC 算法解决。

总结

当 48k 高音质成了刚需,为了保障采集环节的高质量,一方面需要投入时间去掌握 Android 参数适配的规律,同时市面上出现的越来越多的定制化的 android 设备(手表,智能音箱等),也必不可少的需要先确定好配置参数;另一方面关闭硬件设备自带的音频处理功能,启用 RTC 自带的纯软 3A 算法也是一种趋势,前提是要优化好软件 3A 算法整体效果以及控制好功耗,这也是客户评测各厂家之间音频体验的必测项,也是各厂家的核心竞争力之一。


扫码入群和作者一起探讨音视频技术
获取更多视频云行业最新信息👇

image.png

「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实践技术文章,在这里与音视频领域一流工程师交流切磋。公众号后台回复【技术】可加入阿里云视频云产品技术交流群,和业内大咖一起探讨音视频技术,获取更多行业最新信息。
相关文章
|
2月前
|
安全 API 开发工具
Android平台RTMP推送|轻量级RTSP服务如何实现麦克风|扬声器声音采集切换
Android平台扬声器播放声音的采集,在无纸化同屏等场景下,意义很大,早期低版本的Android设备,是没法直接采集扬声器audio的(从Android 10开始支持),所以,如果需要采集扬声器audio,需要先做系统版本判断,添加相应的权限。
|
应用服务中间件 nginx
流媒体技术学习笔记之(十四)FFmpeg进行笔记本摄像头+麦克风实现流媒体直播服务
FFmpeg推送视频流,Nginx RTMP模块转发,VLC播放器播放,实现整个RTMP直播 查看本机电脑的设备 ffmpeg -list_devices true -f dshow -i dummy 红色标记表示视频设备和麦克风设备 看到乱码了吧!来这里查看哦   FFmpeg编码推送到R...
3492 0
|
6月前
|
Linux C++ iOS开发
VLC源码解析:视频播放速度控制背后的技术
VLC源码解析:视频播放速度控制背后的技术
586 0
|
XML 存储 编解码
浅浅地优化下视频流播放体验
浅浅地优化下视频流播放体验
614 0
|
传感器 编解码 API
大彩串口屏在RTOS编程中应该注意的要点
大彩串口屏在RTOS编程中应该注意的要点
219 0
大彩串口屏在RTOS编程中应该注意的要点
|
编解码 Android开发
Android平台GB28181设备接入、RTMP推送模块如何实现高效率的视频编码
我们在做Android平台RTMP推送、轻量级RTSP服务和GB28181设备接入模块的时候,有一个点是逃不掉的:如何高效率的实现视频数据编码?
188 0
|
开发工具 Android开发 开发者
Android平台RTMP推流或轻量级RTSP服务(摄像头或同屏)编码前数据接入类型总结
很多开发者在做Android平台RTMP推流或轻量级RTSP服务(摄像头或同屏)时,总感觉接口不够用,以大牛直播SDK为例 (Github) 我们来总结下,我们常规需要支持的编码前音视频数据有哪些类型:
159 0
|
编解码 缓存 Linux
对话音视频牛哥:如何设计功能齐全的跨平台低延迟RTMP播放器
对话音视频牛哥:如何设计功能齐全的跨平台低延迟RTMP播放器
158 0
|
编解码
播放器实战--音视频同步方案
播放器实战--音视频同步方案
188 0
|
缓存 Java 索引
浅浅地优化下视频流播放体验(下)
浅浅地优化下视频流播放体验
343 0