簡介：在去年疫情期間，在線教育行業獲得了井噴式的發展，這背后的技術功臣非 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 進一步探索優化。

「視頻云技術」你最值得關注的音視頻技術公眾號，每周推送來自阿里云一線的實踐技術文章，在這里與音視頻領域一流工程師交流切磋。

原文鏈接：https://developer.aliyun.com/article/783023?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的用 RTC 打造一个音乐教育 App，需要解决哪些音质难题？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。