簡(jiǎn)介：在去年疫情期間，在線教育行業(yè)獲得了井噴式的發(fā)展，這背后的技術(shù)功臣非 RTC 莫屬。本文將分享 RTC 技術(shù)在音樂教育場(chǎng)景下的實(shí)踐經(jīng)驗(yàn)。

作者｜ 逸城??

審校｜ 泰一

音樂教育場(chǎng)景 - 在線陪練

2020 年的新冠疫情改變了在線教育中素質(zhì)教育行業(yè)的生態(tài)，音樂陪練是其中的典型場(chǎng)景。眾多線下琴行因無法承擔(dān)高昂的租金關(guān)門，在線音樂教育平臺(tái)用戶激增，這其中的代表有 The One、VIP 陪練、快陪練、美悅陪練、音樂筆記等。根據(jù)公開信息，目前 VIP 陪練的日上課量達(dá)到 3 萬節(jié)，快陪練在 2020 年 10 月用戶突破 120 萬。有投資機(jī)構(gòu)指出，到 2022 年，音樂教育市場(chǎng)預(yù)計(jì)達(dá) 4000 多億元規(guī)模，而在線陪練市場(chǎng)的需求近千億元。

但是打造一款傳遞高音質(zhì)的陪練 App 并非易事，在實(shí)際開發(fā)過程中音樂陪練類 App 相比普通在線教育 App 的音質(zhì)的要求更高，下面我將以鋼琴教育為例，從技術(shù)角度來分析 WebRTC 在樂器教育場(chǎng)景下遇到的問題以及解決方案。

樂器類頻譜

以鋼琴類為例，頻譜主要集中在 5KHz 以下，下圖是一段 44.1khz 采樣率的鋼琴曲的音樂經(jīng)過 FFmpeg 解碼后的頻譜圖，從下圖可以看到，考慮到實(shí)際錄音場(chǎng)景可能存在高頻諧波或者其他環(huán)境音的影響，頻率范圍集中在 7kHz 以下頻段：

音質(zhì)影響因素分析

錄音

WebRTC 在音頻采集后的前處理流程是：record->ans->aec->agc。我們先分析第一個(gè)環(huán)節(jié)，錄音的影響。下面測(cè)試基于 Andorid 手機(jī)播放鋼琴曲，手機(jī)距離 Mac 電腦 15cm 左右，在單講模式下，原始鋼琴曲頻譜如下：

經(jīng)過錄音后的頻譜如下：

圖中 400Hz 以下的頻譜基本損失殆盡，考慮到聲音從手機(jī)播放，經(jīng)過手機(jī)揚(yáng)聲器，空氣傳輸，再經(jīng)過對(duì)端 mic 接收，與真實(shí)鋼琴教育場(chǎng)景不太一樣，所以我們錄制了一段真實(shí)鋼琴教育的語料如下：

可以看出真實(shí)的鋼琴教育錄音下頻譜保真度還是與手機(jī)播放再錄制有差異的，因此錄音的因素在真實(shí)鋼琴場(chǎng)景可以暫不考慮。

3A 算法

單講情況下（aec 未生效）：錄音音頻：

經(jīng)過 ans 后頻譜：

結(jié)論：經(jīng)過 ans 后頻率有較大損失，中高頻部分損失較為嚴(yán)重。

雙講情況下（經(jīng)過 ans 和 aec）：

ans 后頻譜（遠(yuǎn)端有人說話）：

aec 后頻譜:

雙講情況對(duì)音樂損失也很大，重點(diǎn)是 aec 模塊損失大。

編解碼器

Opus 是由 SILK+CELT 混合的編碼器，學(xué)術(shù)上的叫法叫做 USAC，Unify Speech and Audio Coding， 不區(qū)分音樂語音的編解碼器。這個(gè)編解碼器內(nèi)有個(gè) Music detector 去判斷當(dāng)前幀是語音還是音樂，語音選擇 silk 框架編碼，音樂選擇 celt 框架編碼，通常建議不限制編碼器固定采用哪種模式編碼。

目前 WebRTC 采用 Application 是 kvoip，默認(rèn)開啟混合編碼模式，并未限制固定是 celt only 或者 silk only 模式。

編碼器內(nèi)混合編碼模式下的音樂與語音編碼算法判決：

測(cè)試語料：

選擇音樂模式編碼 + 混合編碼后：

選擇語音編碼 + 混合編碼模式后：

測(cè)試反饋顯示音樂編碼的情況下切換 silk 模式很靈敏，但是如果采用 VoIP 模式下對(duì)音樂切換不夠靈敏，會(huì)出現(xiàn)語音后對(duì)音樂下延遲為 silk 編碼的情況；因此，語音編碼后的幾秒種內(nèi) silk 編碼對(duì)高頻部分略有損失，相比 celt 編碼略差。

小結(jié)

綜上所述，影響鋼琴教育音質(zhì)的因素主要是降噪模塊和回聲消除模塊。

鋼琴教育場(chǎng)景下的技術(shù)方案

完整的解決方案需要考慮鋼琴教育場(chǎng)景下語音和音樂共存的情況，需要對(duì)當(dāng)前的語音幀做模式判別，識(shí)別是語音還是音樂，如果是語音幀則走正常的 3A 處理流程，如果是音樂幀則需要調(diào)整 3A 的算法，最大限度保證音樂的完整性。

大致流程圖如下：

相關(guān)技術(shù)問題

分析了影響鋼琴教育場(chǎng)景下的因素及技術(shù)方案，下面主要從實(shí)現(xiàn)的角度分析遇到的相關(guān)技術(shù)問題。根據(jù)上面的分析結(jié)論，通常在 VoIP 場(chǎng)景下，ios 和 android 采用了硬件 3A 的方案，但是在樂器教育場(chǎng)景下，則必須采用軟件 3A 的方案，否則 3A 算法無法根據(jù)音樂和人聲動(dòng)態(tài)調(diào)整。

1. iOS 平臺(tái)采集模式問題

WebRTC 在 iOS 平臺(tái)用的是 AudioUnit 采集，相關(guān)代碼如下：

根據(jù)蘋果的 API 說明，iOS 提供了三個(gè) I/O units，其中 Remote I/O unit 是最常用的。連接輸入輸出音頻硬件，對(duì)傳入和傳出的樣本值低延遲訪問，提供硬件音頻格式和應(yīng)用音頻格式之間的格式轉(zhuǎn)化。Voice-Processing I/O unit 是對(duì) Remote I/O unit 的拓展，添加了語音聊天中的回聲消除，還提供了自動(dòng)增益矯正，語音質(zhì)量調(diào)整，靜音等特性。Generic Output unit 不連接音頻硬件，而是提供了一種將處理鏈的輸出發(fā)送到應(yīng)用程序的機(jī)制。通常會(huì)使用做離線音頻處理。

因此，在樂器教育場(chǎng)景下，需要初始化 AudioUnit 的類型設(shè)置為 Remote I/O 模式，這樣錄音數(shù)據(jù)不會(huì)經(jīng)過硬件 3A 處理。但是在啟用 Remote I/O 模式下后，錄音數(shù)據(jù)如下：

發(fā)現(xiàn)啟用 Remote I/O 后，系統(tǒng)硬件也不做音量增益，因此導(dǎo)致錄進(jìn)去的音量很低（-14db 左右）， 因此，對(duì)應(yīng)的軟件 agc 算法增益也需要針對(duì)性調(diào)整。

2. Andorid 平臺(tái)采集模式問題

通常，在 Android 平臺(tái)，VoIP 模式下，通過適配，大

部分機(jī)型可以使用硬件 3A，這樣既可以保證效果，又可以帶來更低的功耗和延時(shí)。而 Andoird 平臺(tái)又為 Java 的采集播放和 Opensles 的采集播放兩種方式可以選擇，通常經(jīng)驗(yàn)下 opensles 的延遲更小，并且適配性更好。我們接下來也以 opensles 為例來介紹 VoIP 場(chǎng)景和樂器教育場(chǎng)景下的設(shè)置不同之處。opensles 提供了 audiosource 和 audiotype 的幾種模式供選擇：

以 VoIP 場(chǎng)景為例，opensles 的通常選擇是 audiosource:VOICE_COMMUNICATION, stream_type:STREAM_VOICE；但是如果是樂器教育場(chǎng)景，則需要采用 audiosource: MIC, stream_type:STREAM_MEDIA 的組合方式，否則容易出現(xiàn)觸發(fā)啟動(dòng)硬件 3A 的情況。

下圖就是小米手機(jī)里設(shè)置 audiosouce: MIC, stream_type: STREAM_VOICE 下對(duì)音樂的采集效果，圖中可以看到由于 stream_type 設(shè)置的模式不對(duì)，在播放的時(shí)候就會(huì)影響系統(tǒng)采集觸發(fā)硬件 3A, 對(duì)音樂信號(hào)造成嚴(yán)重的損傷。

3. 音樂和語音檢測(cè)模塊問題

上篇文章提到，opus 提供了語音和音樂檢測(cè)模塊，根據(jù)測(cè)試，在編碼器設(shè)置默認(rèn)為音樂時(shí)對(duì)語音和音樂的檢測(cè)很靈敏，但是如果設(shè)置為語音編碼模式時(shí)當(dāng)由語音切換為音樂時(shí)存在數(shù)秒左右的算法檢測(cè)滯后，仔細(xì)分析 opus 代碼如下：

編碼器在做模式判決時(shí)會(huì)根據(jù)設(shè)置的默認(rèn)編碼模式來設(shè)置門限值，語音編碼下的門限值會(huì)調(diào)高，這種做法是當(dāng)由語音切換為音樂時(shí)編碼器不馬上切換音樂模式，以便于最大限度保留語音信息，因?yàn)檎Z音信息的幀間相關(guān)性會(huì)比較強(qiáng)。

因此在鋼琴教育場(chǎng)景建議默認(rèn)采用音樂編碼方式，以便于最大程度保留音樂信息，減少 3A 處理對(duì)音質(zhì)造成的損傷。

總結(jié)

基于 WebRTC 的音樂教育場(chǎng)景的工程化實(shí)踐有不少細(xì)節(jié)需要考慮，從音頻信號(hào)的采集，到 3A 的適配，再到音頻編碼器的參數(shù)調(diào)整，都需要做針對(duì)性調(diào)優(yōu)，才能最大限度的做到既能保證語音信號(hào)的清晰可辨，又能保證音樂信號(hào)的細(xì)節(jié)豐富而不失真。另外，隨著在線教育細(xì)分市場(chǎng)的不斷成熟，針對(duì)部分特殊樂器比如打擊類樂器的場(chǎng)景，又會(huì)帶來新的技術(shù)難點(diǎn)，需要 RTC 進(jìn)一步探索優(yōu)化。

「視頻云技術(shù)」你最值得關(guān)注的音視頻技術(shù)公眾號(hào)，每周推送來自阿里云一線的實(shí)踐技術(shù)文章，在這里與音視頻領(lǐng)域一流工程師交流切磋。

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

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。