用 WebRTC 打造一个音乐教育 App，要解决哪些音质难题？
在去年疫情期间，在线教育行业获得了井喷式的发展，这背后的技术功臣非 RTC 莫属。本文将分享 RTC 技术在音乐教育场景下的实践经验。
作者｜ 逸城
审校｜ 泰一
音乐教育场景 - 在线陪练
2020 年的新冠疫情改变了在线教育中素质教育行业的生态，音乐陪练是其中的典型场景。众多线下琴行因无法承担高昂的租金关门，在线音乐教育平台用户激增，这其中的代表有 The One、VIP 陪练、快陪练、美悦陪练、音乐笔记等。根据公开信息，目前 VIP 陪练的日上课量达到 3 万节，快陪练在 2020 年 10 月用户突破 120 万。有投资机构指出，到 2022 年，音乐教育市场预计达 4000 多亿元规模，而在线陪练市场的需求近千亿元。
但是打造一款传递高音质的陪练 App 并非易事，在实际开发过程中音乐陪练类 App 相比普通在线教育 App 的音质的要求更高，下面我将以钢琴教育为例，从技术角度来分析 WebRTC 在乐器教育场景下遇到的问题以及解决方案。
乐器类频谱
以钢琴类为例，频谱主要集中在 5KHz 以下，下图是一段 44.1khz 采样率的钢琴曲的音乐经过 FFmpeg 解码后的频谱图，从下图可以看到，考虑到实际录音场景可能存在高频谐波或者其他环境音的影响，频率范围集中在 7kHz 以下频段：
音质影响因素分析
录音
WebRTC 在音频采集后的前处理流程是：record->ans->aec->agc。我们先分析第一个环节，录音的影响。下面测试基于 Andorid 手机播放钢琴曲，手机距离 Mac 电脑 15cm 左右，在单讲模式下，原始钢琴曲频谱如下：
经过录音后的频谱如下：
图中 400Hz 以下的频谱基本损失殆尽，考虑到声音从手机播放，经过手机扬声器，空气传输，再经过对端 mic 接收，与真实钢琴教育场景不太一样，所以我们录制了一段真实钢琴教育的语料如下：
可以看出真实的钢琴教育录音下频谱保真度还是与手机播放再录制有差异的，因此录音的因素在真实钢琴场景可以暂不考虑。
3A 算法
单讲情况下（aec 未生效）：录音音频：
经过 ans 后频谱：
结论：经过 ans 后频率有较大损失，中高频部分损失较为严重。
双讲情况下（经过 ans 和 aec）：
ans 后频谱（远端有人说话）：
aec 后频谱:
双讲情况对音乐损失也很大，重点是 aec 模块损失大。
编解码器
Opus 是由 SILK CELT 混合的编码器，学术上的叫法叫做 USAC，Unify Speech and Audio Coding， 不区分音乐语音的编解码器。这个编解码器内有个 Music detector 去判断当前帧是语音还是音乐，语音选择 silk 框架编码，音乐选择 celt 框架编码，通常建议不限制编码器固定采用哪种模式编码。
目前 WebRTC 采用 Application 是 kvoip，默认开启混合编码模式，并未限制固定是 celt only 或者 silk only 模式。
编码器内混合编码模式下的音乐与语音编码算法判决：
测试语料：
选择音乐模式编码 混合编码后：
选择语音编码 混合编码模式后：
测试反馈显示音乐编码的情况下切换 silk 模式很灵敏，但是如果采用 VoIP 模式下对音乐切换不够灵敏，会出现语音后对音乐下延迟为 silk 编码的情况；因此，语音编码后的几秒种内 silk 编码对高频部分略有损失，相比 celt 编码略差。
小结
综上所述，影响钢琴教育音质的因素主要是降噪模块和回声消除模块。
钢琴教育场景下的技术方案
完整的解决方案需要考虑钢琴教育场景下语音和音乐共存的情况，需要对当前的语音帧做模式判别，识别是语音还是音乐，如果是语音帧则走正常的 3A 处理流程，如果是音乐帧则需要调整 3A 的算法，最大限度保证音乐的完整性。
大致流程图如下：
相关技术问题
分析了影响钢琴教育场景下的因素及技术方案，下面主要从实现的角度分析遇到的相关技术问题。根据上面的分析结论，通常在 VoIP 场景下，ios 和 android 采用了硬件 3A 的方案，但是在乐器教育场景下，则必须采用软件 3A 的方案，否则 3A 算法无法根据音乐和人声动态调整。
1. iOS 平台采集模式问题
WebRTC 在 iOS 平台用的是 AudioUnit 采集，相关代码如下：
根据苹果的 API 说明，iOS 提供了三个 I/O units，其中 Remote I/O unit 是最常用的。连接输入输出音频硬件，对传入和传出的样本值低延迟访问，提供硬件音频格式和应用音频格式之间的格式转化。Voice-Processing I/O unit 是对 Remote I/O unit 的拓展，添加了语音聊天中的回声消除，还提供了自动增益矫正，语音质量调整，静音等特性。Generic Output unit 不连接音频硬件，而是提供了一种将处理链的输出发送到应用程序的机制。通常会使用做离线音频处理。
因此，在乐器教育场景下，需要初始化 AudioUnit 的类型设置为 Remote I/O 模式，这样录音数据不会经过硬件 3A 处理。但是在启用 Remote I/O 模式下后，录音数据如下：
发现启用 Remote I/O 后，系统硬件也不做音量增益，因此导致录进去的音量很低（-14db 左右）， 因此，对应的软件 agc 算法增益也需要针对性调整。
2. Andorid 平台采集模式问题
通常，在 Android 平台，VoIP 模式下，通过适配，大部分机型可以使用硬件 3A，这样既可以保证效果，又可以带来更低的功耗和延时。而 Andoird 平台又为 Java 的采集播放和 Opensles 的采集播放两种方式可以选择，通常经验下 opensles 的延迟更小，并且适配性更好。我们接下来也以 opensles 为例来介绍 VoIP 场景和乐器教育场景下的设置不同之处。opensles 提供了 audiosource 和 audiotype 的几种模式供选择：
以 VoIP 场景为例，opensles 的通常选择是 audiosource:VOICE_COMMUNICATION, stream_type:STREAM_VOICE；但是如果是乐器教育场景，则需要采用 audiosource: MIC, stream_type:STREAM_MEDIA 的组合方式，否则容易出现触发启动硬件 3A 的情况。
下图就是小米手机里设置 audiosouce: MIC, stream_type: STREAM_VOICE 下对音乐的采集效果，图中可以看到由于 stream_type 设置的模式不对，在播放的时候就会影响系统采集触发硬件 3A, 对音乐信号造成严重的损伤。
3. 音乐和语音检测模块问题
上篇文章提到，opus 提供了语音和音乐检测模块，根据测试，在编码器设置默认为音乐时对语音和音乐的检测很灵敏，但是如果设置为语音编码模式时当由语音切换为音乐时存在数秒左右的算法检测滞后，仔细分析 opus 代码如下：
编码器在做模式判决时会根据设置的默认编码模式来设置门限值，语音编码下的门限值会调高，这种做法是当由语音切换为音乐时编码器不马上切换音乐模式，以便于最大限度保留语音信息，因为语音信息的帧间相关性会比较强。
因此在钢琴教育场景建议默认采用音乐编码方式，以便于最大程度保留音乐信息，减少 3A 处理对音质造成的损伤。
总结
基于 WebRTC 的音乐教育场景的工程化实践有不少细节需要考虑，从音频信号的采集，到 3A 的适配，再到音频编码器的参数调整，都需要做针对性调优，才能最大限度的做到既能保证语音信号的清晰可辨，又能保证音乐信号的细节丰富而不失真。另外，随着在线教育细分市场的不断成熟，针对部分特殊乐器比如打击类乐器的场景，又会带来新的技术难点，需要 RTC 进一步探索优化。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。