RT-Thread智能音箱音频应用实践
國內(nèi)智能音箱的問世早于國外,但由于國內(nèi)對智能化概念普及程度較低,初期智能音箱并沒有受到很多關(guān)注。但近幾年國內(nèi)智能音箱行業(yè)經(jīng)歷了從百花齊放到三足鼎立的發(fā)展階段,來自RT-Thread的黃天翔將從占據(jù)主流市場的三個廠商脫穎而出的秘訣開始,分享RT-Thread在智能音箱在音頻方面的內(nèi)容。
文 / 黃天翔
整理 / LiveVideoStack
智能音箱現(xiàn)狀
2014年10月,Alexa一款名為 Echo 的智能音箱出現(xiàn),智能音箱行業(yè)開始火爆并受到極大關(guān)注。2015年年底,全球智能音箱銷量達到250萬臺。
國內(nèi)智能音箱的問世早于國外,但由于國內(nèi)對智能化概念普及程度較低,初期智能音箱并沒有受到很多關(guān)注。2015年京東叮咚系列音箱問世,2016年國內(nèi)的美的、酷狗等多家公司涉足智能音箱行業(yè),到2017年智能音箱市場全面爆發(fā),2018年各大廠商已完成智能音箱的全面布局。
國內(nèi)智能音箱行業(yè)經(jīng)歷了從百花齊放到三足鼎立的發(fā)展階段,到2018年底,阿里、小米、百度三家獨占鰲頭,占據(jù)主流市場。
我們分析了三個廠商能脫穎而出的秘訣:首先百度用低價爆款的策略,以輕量化、小巧的產(chǎn)品迅速沖擊市場。
其次,如上右側(cè)圖所示,在兩年內(nèi)國內(nèi)廠商推出了多款智能音箱產(chǎn)品。從這些產(chǎn)品可以發(fā)現(xiàn)智能音箱大熱還有一個重要因素:使用高性能芯片以及使用Linux系統(tǒng)方案。智能音箱涉及多方面難點技術(shù),選用成本較高的方案快速迭代是市場得以推進的重要原因。
上圖所示的是兩種主流智能音箱的方案。百度小度智能音箱選用了Amlogic A113X1.5G 芯片配套 Linux 方案。小米音箱則是選用了全志 R16 A7四核心芯片。
基于現(xiàn)有方案可以預(yù)測,后續(xù)各廠商將會尋找低成本且同時也能滿足快捷開發(fā)、穩(wěn)定的方案替代,越來越多中端廠商在考慮能否使用RTOS方案代替Linux方案。
Linux向RTOS方案遷移分析
?
如上圖所示的兩種方案,當(dāng)前方案中使用的是高端芯片,未來則會選擇一些中低端甚至ARM9芯片完成智能音箱系統(tǒng)的開發(fā)。我們可以看到,目前方案從外接WIFI、藍牙芯片轉(zhuǎn)為使用內(nèi)置芯片,包括芯片、MCU、DSP等都發(fā)生了變化。從封裝來看,它從BGA封裝變?yōu)镼FN封裝,生產(chǎn)成本明顯降低。RTOS主打?qū)崟r系統(tǒng),開機速度降低到一兩秒,此外,它還有功耗低等特性。RTOS在智能音箱領(lǐng)域有一定優(yōu)勢,例如在ACE回采時,我們會做主動喚醒,有固定的時間窗口使回采算法更可靠,時間不固定時回采數(shù)據(jù)不及時,RTOS可對時間窗口做極大保證。
?
上圖是通用方案啟動速度對比。我們可以看出系統(tǒng)分為Boot、OS、APP啟動三個層面。從三個層面整體來看,Linux系統(tǒng)啟動需要10秒左右,而使用RTOS方案啟動時間只有一兩秒。
?
如上圖,我們從四個方面做了對比。如大家所知,Linux所需的RAM、Flash是比較高的。ARM cortex-A方案是主流高端方案需要32MB RAM 和64MB Flash 的消耗。據(jù)我們統(tǒng)計,遷移 RTOS 方案 后可做到2MB RAM 和 4MB Flash 左右的消耗。由于 RTOS 系統(tǒng)比較輕巧,我們可以使用更小的RAM、Flash 芯片。
?
除了以上優(yōu)勢,RTOS也有生態(tài)劣勢。智能音箱的操作系統(tǒng)更需要涉及到網(wǎng)絡(luò)、音頻相關(guān)的內(nèi)容。Linux系統(tǒng)有成熟穩(wěn)定的網(wǎng)絡(luò)框架、音頻子系統(tǒng)以及ffmpeg、Curl等開源軟件。RTOS調(diào)度器則更多的使用了輕量級網(wǎng)絡(luò)協(xié)議棧,在音頻方面比較空缺,公司各有私有的方案,成本比較高。
?
?
我們使用RTOS研發(fā)音頻播放系統(tǒng)鑒于成本趨勢、系統(tǒng)資源問題和開發(fā)成本的綜合考慮,希望能完成一套比較完整成熟的音頻系統(tǒng)。
RT-Thread?網(wǎng)絡(luò)音頻播放器設(shè)計的迭代
如上圖是我們第一版音頻播放器方案框架。早期設(shè)計這一款播放器,沒有考慮網(wǎng)絡(luò)播放的相關(guān)的功能。這版邏輯比較簡單:獲取音頻數(shù)據(jù)后直接做解碼,解碼過程是一個循環(huán)邏輯,單線程等待外部響應(yīng)事件,包括seek事件、暫停恢復(fù)事件、停止事件完成播放器邏輯,最后將解析出的數(shù)據(jù)寫入底層音頻驅(qū)動。
由于第一版不滿足網(wǎng)絡(luò)播放的市場需求,我們將網(wǎng)絡(luò)組件、網(wǎng)絡(luò)功能添加到了系統(tǒng)中。如上圖中紅色邏輯處理部分。在這部分我們對框架思路做了修改,將文件、網(wǎng)絡(luò)資源放到同一層,選擇本地或網(wǎng)絡(luò)下載音頻資源,整體呈單線程模式。無論打開的URL資源是本地資源還是網(wǎng)絡(luò)資源,都是獲得資源后做解碼播放 。
這版播放器隨著在項目中越來越多的使用,逐漸的出現(xiàn)了很多噪音卡頓拖慢等問題。如上圖是我們PCM項目回采得出的數(shù)據(jù)分析結(jié)果。我們在播放音頻出現(xiàn)了短暫噪音之后繼續(xù)播放的情況,后期多方面分析發(fā)現(xiàn),這是由于網(wǎng)絡(luò)情況不穩(wěn)定,解碼器短暫接收不到數(shù)據(jù)造成的。
如上圖所示網(wǎng)絡(luò)不可靠的原因有多種,很多網(wǎng)絡(luò)不穩(wěn)定是網(wǎng)絡(luò)硬件造成的波動,軟件層面是無法完全避免的,我們只能通過軟件算法和思路減少這些問題造成的影響。
如上圖是我們第三版改進后的播放器框架圖。左側(cè)是一樣的,依然是獲取數(shù)據(jù)進行解碼,唯一不同的是我會從網(wǎng)絡(luò)緩存區(qū)獲取數(shù)據(jù)。啟動播放后,我們會啟動一個新線程將本地數(shù)據(jù)或網(wǎng)絡(luò)音頻寫入緩存區(qū),將下載與解碼器分離。只要緩存區(qū)有數(shù)據(jù),解碼播放便不會出現(xiàn)卡頓。
我們采用了帶RTOS 喚醒調(diào)度機制且具有水位線管理的 pipe 作為第三版的音頻緩沖區(qū) 。例如我們設(shè)置了一個512KB的緩存區(qū),通過HTTP連接下載數(shù)據(jù)。如果緩存區(qū)中沒有數(shù)據(jù),我們可以簡單認(rèn)為下載與解碼同時進行的。解碼時緩存區(qū)沒有數(shù)據(jù)時會等待直到音頻數(shù)據(jù)高于水位線。水位線即可開始解碼的最低緩存數(shù)據(jù)量。我們做了一個可動態(tài)調(diào)節(jié)的水位線機制。
改進過后,我們做了一個測試。如上圖左側(cè)是我們的測試環(huán)境數(shù)據(jù)。V2版本中,理論上音樂碼率大于1411kbps時才支持播放。而V3版本中,當(dāng)下載速度大于播放速度時會導(dǎo)致水位上漲,一定會出現(xiàn)高于水位線情況。當(dāng)網(wǎng)絡(luò)出現(xiàn)卡頓時,緩存數(shù)據(jù)是高于水位線的,解碼器依然可以拿到數(shù)據(jù)。
在另一種測試環(huán)境時,當(dāng)下載速度一直低于播放速度。這是一種極端情況,下載達不到規(guī)定碼率,無論如何播放都絕對不會流暢。V2版本中音頻會一直間隔卡頓導(dǎo)致用戶無法聽清內(nèi)容。在水位線機制中,當(dāng)碼率較低,緩存不夠時是不會發(fā)出聲音的,會有一秒的緩存時間,緩存過后播放的聲音是較長時間連續(xù)的。,這樣我們能夠提升一定會卡頓情況下的用戶體驗,讓在非常卡頓的網(wǎng)絡(luò)情況下音頻不再發(fā)出刺耳的噪音。
有時我們會播放一些相聲、新聞等實時音頻電臺流內(nèi)容。和音樂文件有一些不同,這時會出現(xiàn)推送流碼率和播放流碼率相同的情況。
這種情況的解決涉及到變速不變調(diào)算法的使用,即我們會改變語音播放速度而不改變語義語調(diào),改變較小時人耳不會聽到差別。如上圖我們做了測試。當(dāng)下載碼率與播放碼率相同時,我們通過變速不變調(diào)算法降低音頻的播放碼率,下載速度會始終大于播放速度。如圖中所示,雖然我們會進行緩存,但是由于下載速度較小,水位線漲不上去,依然會出現(xiàn)一定卡頓。經(jīng)處理后,下載速度大于播放速度后,水位線會持續(xù)上漲,開始播放后便可以降低出現(xiàn)卡頓的情況。
基于以上,我們完成了第四版的改進。我們在寫入底層播放驅(qū)動前做對每一幀做變速不變調(diào)算法處理,當(dāng)然這是可以選擇開啟的功能。
除了可以做變速不變調(diào)處理,我們還可以在相同位置EQ算法均衡器等其它處理,實現(xiàn)流行音樂音效、超低音音效等效果。
于是我們又做了一次改進。我們將變速不變調(diào)做了剝離,以插件的形式動態(tài)選擇不同音效。
在智能音箱領(lǐng)域,客戶會使用多種容器、協(xié)議以及編碼格式。我們需要支持多種組合。
我們在原基礎(chǔ)上做了改進,改進點如上圖紅色部分所示。在之前版本中,我們會將數(shù)據(jù)直接下載緩存到緩存區(qū)進行解碼。改進后,我們將解碼和解容器進行分離,在下載中加入了解容器,播放過程中解碼。解容器以插件形式接入系統(tǒng),在播放過程中探測它的格式,選用合適的容器解碼格式。在這個過程中,不僅可以實現(xiàn)了多格式容器解碼,也實現(xiàn)了多協(xié)議解碼。我們將下載線程進行分類,針對不同協(xié)議做下載邏輯。將容器、協(xié)議、解碼器剝離后,播放器框架可實現(xiàn)多種組合應(yīng)用場景。
混音框架設(shè)計
接下來我將介紹智能音箱設(shè)計過程中遇到的另一個重要問題。如上圖左側(cè)部分,音箱服務(wù)器推送了一個音頻,在播放過程中突然需要播放提示音,通常我們需要將音頻暫停播放,插入提示音,播放完成后音頻恢復(fù)播放。在這種情況下,設(shè)備需要維護播放狀態(tài)的。如圖中原始音頻是44K,采樣率是16K,中間有采樣率切換的過程。切換采樣率的過程中,需要注意它的實時性,因為我們控制內(nèi)部芯片會產(chǎn)生一定時延。另一個就是pop音問題,當(dāng)還有音頻在播放時,切換采樣率會有噪音出現(xiàn)。對此,我們做出了部分改進,采用混音的思路:將原音頻音量降低,再采用混音的方式將提示音混入,提示音播放完成后恢復(fù)音頻音量。這種思路不需要考慮播放器播放狀態(tài)的維護,而且兩路音頻完全獨立,開發(fā)者邏輯代碼編寫也清晰簡單。
我們在做這個方案時評估了Linux下的一個成熟算法。算法采用了線性重采樣算法。如上圖,它的庫里有五種模式,默認(rèn)使用最低模式。我們使用ARM-CotexM4芯片做了測試,發(fā)現(xiàn)最多模式會占用百分之八十CPU。
libsamplerate算法輸入的數(shù)據(jù)是浮點類型,使用此算法先將數(shù)據(jù)切為單精度浮點數(shù),內(nèi)部使用雙精度浮點數(shù)做計算采樣以確保采樣效果。如圖中48K音頻采樣耗費了115%CPU,重采樣過程花費三百多秒。我們對此做了改進。我們對輸入?yún)?shù)使用整形定點算法,這時占用CPU降到了79%。我們又將內(nèi)部雙精度浮點數(shù)強制降為單精度后,CPU占用率降到了49.5%。最終,我們做成了全整形數(shù),這時CPU占用只有3.8%。另外,由于重采樣算法由C語言寫成,我們從匯編層面對它做了優(yōu)化,之前的操作造成了采樣效果變差,通過匯編優(yōu)化將32位整型數(shù)改為了64位,整體效果雖不及浮點數(shù),但整體效果提升了很多。
?
市面上主流混音算法模型有幾種,第一種是兩個聲道數(shù)據(jù)直接加和,當(dāng)某一通道的數(shù)據(jù)幅度較大時混音后任意出現(xiàn)音頻數(shù)據(jù)溢出,從而音頻失真。第二種是加和后再除以音道數(shù)防止溢出,這樣會造成音道內(nèi)音量衰減,并且音軌越多衰減越多。還有一種是加和箝位,即相加超過最大值時進行限幅,這樣音頻也會失真。另外還有飽和處理、歸一化處理等。考慮到RTOS 方案應(yīng)用場景是一個音軌音量高一個音量稍低,我們并需要兩個聲音同時聽清,我們只需要保證一個音軌的質(zhì)量。最終我們選擇了圖中第二種算法。雖然會產(chǎn)生一些衰減,但是在這個場景下只保證兩個音道中一個聲音清晰,衰減是可以忽略的。但是其它算法可能會出現(xiàn)失真,這是不能接受的。這種方案在實際應(yīng)用中效果很好的。
?
上圖是我們測試結(jié)果。圖中是一幀數(shù)據(jù)、20毫秒的窗口,我們做了重采樣混音算法。優(yōu)化過后,主音軌重采樣耗了大概1.288毫秒,副音軌耗了1.296毫秒,混音用時1.281毫秒,在ARM9 120MHZ的系統(tǒng)中耗費了大概20%的CPU消耗。
LiveVideoStackCon 2020
上海/北京/舊金山 講師招募
2020年LiveVideoStackCon將持續(xù)迭代,LiveVideoStackCon將分別在上海(6月13-14日),北京(9月11-12日)和舊金山(11月)舉行。歡迎將你的技術(shù)實踐、踩坑與填坑經(jīng)歷、技術(shù)與商業(yè)創(chuàng)業(yè)的思考分享出來,獨樂不如眾樂。請將個人資料和話題信息郵件到 speaker@livevideostack.com 或點擊【閱讀原文】了解成為LiveVideoStackCon講師的權(quán)益與義務(wù),我們會在48小時內(nèi)回復(fù)。
總結(jié)
以上是生活随笔為你收集整理的RT-Thread智能音箱音频应用实践的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 音视频技术开发周刊 | 135
- 下一篇: FPGA+CPU助力数据中心实现图像处理