作者｜ 逸城
審校｜ 泰一
音樂教育場景 - 線上陪練
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 進一步探索優化。
「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。