國內(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)容，希望文章能夠幫你解決所遇到的問題。

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