简介： 在去年疫情期间，在线教育行业取得了井喷式的倒退，这背地的技术功臣非 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 进一步摸索优化。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。