提升 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

「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实践技术文章,在这里与音视频领域一流工程师交流切磋。公众号后台回复【技术】可加入阿里云视频云产品技术交流群,和业内大咖一起探讨音视频技术,获取更多行业最新信息。
相关文章
|
7月前
|
开发工具 Android开发
Android平台GB28181设备接入端语音广播技术探究和填坑指南
GB/T28181-2016官方规范和交互流程,我们不再赘述。
|
7月前
|
编解码 开发工具 Android开发
Android平台RTSP轻量级服务|RTMP推送摄像头或屏幕之音频接口设计
好多开发者在做Android平台录像或者RTSP轻量级服务、RTMP推送相关模块时,对需要设计哪些常用接口会心存疑惑,本文主要以大牛直播SDK(官方)为例,简单介绍下Android平台直播推送SDK所有音频相关的接口,感兴趣的开发者可以看看。
|
1月前
|
Linux C++ iOS开发
VLC源码解析:视频播放速度控制背后的技术
VLC源码解析:视频播放速度控制背后的技术
81 0
|
2月前
|
编解码 网络协议 Unix
相较于ffmpeg我更倾向于使用socket实现推流工作
相较于ffmpeg我更倾向于使用socket实现推流工作
31 0
|
应用服务中间件 nginx
流媒体技术学习笔记之(十四)FFmpeg进行笔记本摄像头+麦克风实现流媒体直播服务
FFmpeg推送视频流,Nginx RTMP模块转发,VLC播放器播放,实现整个RTMP直播 查看本机电脑的设备 ffmpeg -list_devices true -f dshow -i dummy 红色标记表示视频设备和麦克风设备 看到乱码了吧!来这里查看哦   FFmpeg编码推送到R...
3328 0
|
7月前
|
传感器 编解码 API
大彩串口屏在RTOS编程中应该注意的要点
大彩串口屏在RTOS编程中应该注意的要点
126 0
大彩串口屏在RTOS编程中应该注意的要点
|
7月前
|
编解码 Android开发
Android平台GB28181设备接入、RTMP推送模块如何实现高效率的视频编码
我们在做Android平台RTMP推送、轻量级RTSP服务和GB28181设备接入模块的时候,有一个点是逃不掉的:如何高效率的实现视频数据编码?
125 0
|
8月前
|
编解码 缓存 Linux
对话音视频牛哥:如何设计功能齐全的跨平台低延迟RTMP播放器
对话音视频牛哥:如何设计功能齐全的跨平台低延迟RTMP播放器
125 0
|
11月前
|
Linux API 开发者
Linux驱动分析之RTC框架
当Linux内核启动时,它会从RTC中读取时间与日期,作为基准值。然后通过软件来维护系统时间和日期。Linux系统中提供了RTC核心层,对于驱动开发者而言,操作起来就变得很简单了。我们来看看整体框架。
|
存储 缓存 网络协议