用 RTC 打造一个音乐教育 App,需要解决哪些音质难题?
作者| 逸城??
審校| 泰一
音樂教育場(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Fluid 0.5 版本:开启数据集缓存
- 下一篇: 重点解决三大环节数字化,高效适配家装数智