國內智能音箱的問(wèn)世早于國外，但由于國內對智能化概念普及程度較低，初期智能音箱并沒(méi)有受到很多關(guān)注。但近幾年國內智能音箱行業(yè)經(jīng)歷了從百花齊放到三足鼎立的發(fā)展階段，來(lái)自RT-Thread的黃天翔將從占據主流市場(chǎng)的三個(gè)廠(chǎng)商脫穎而出的秘訣開(kāi)始，分享RT-Thread在智能音箱在音頻方面的內容。

文 / 黃天翔

整理 / LiveVideoStack

智能音箱現狀

2014年10月，Alexa一款名為 Echo 的智能音箱出現，智能音箱行業(yè)開(kāi)始火爆并受到極大關(guān)注。2015年年底，全球智能音箱銷(xiāo)量達到250萬(wàn)臺。

國內智能音箱的問(wèn)世早于國外，但由于國內對智能化概念普及程度較低，初期智能音箱并沒(méi)有受到很多關(guān)注。2015年京東叮咚系列音箱問(wèn)世，2016年國內的美的、酷狗等多家公司涉足智能音箱行業(yè)，到2017年智能音箱市場(chǎng)全面爆發(fā)，2018年各大廠(chǎng)商已完成智能音箱的全面布局。

國內智能音箱行業(yè)經(jīng)歷了從百花齊放到三足鼎立的發(fā)展階段，到2018年底，阿里、小米、百度三家獨占鰲頭，占據主流市場(chǎng)。

我們分析了三個(gè)廠(chǎng)商能脫穎而出的秘訣：首先百度用低價(jià)爆款的策略，以輕量化、小巧的產(chǎn)品迅速沖擊市場(chǎng)。

其次，如上右側圖所示，在兩年內國內廠(chǎng)商推出了多款智能音箱產(chǎn)品。從這些產(chǎn)品可以發(fā)現智能音箱大熱還有一個(gè)重要因素：使用高性能芯片以及使用Linux系統方案。智能音箱涉及多方面難點(diǎn)技術(shù)，選用成本較高的方案快速迭代是市場(chǎng)得以推進(jìn)的重要原因。

上圖所示的是兩種主流智能音箱的方案。百度小度智能音箱選用了Amlogic A113X1.5G 芯片配套 Linux 方案。小米音箱則是選用了全志 R16 A7四核心芯片。

基于現有方案可以預測，后續各廠(chǎng)商將會(huì )尋找低成本且同時(shí)也能滿(mǎn)足快捷開(kāi)發(fā)、穩定的方案替代，越來(lái)越多中端廠(chǎng)商在考慮能否使用RTOS方案代替Linux方案。

Linux向RTOS方案遷移分析

如上圖所示的兩種方案，當前方案中使用的是高端芯片，未來(lái)則會(huì )選擇一些中低端甚至ARM9芯片完成智能音箱系統的開(kāi)發(fā)。我們可以看到，目前方案從外接WIFI、藍牙芯片轉為使用內置芯片，包括芯片、MCU、DSP等都發(fā)生了變化。從封裝來(lái)看，它從BGA封裝變?yōu)镼FN封裝，生產(chǎn)成本明顯降低。RTOS主打實(shí)時(shí)系統，開(kāi)機速度降低到一兩秒，此外，它還有功耗低等特性。RTOS在智能音箱領(lǐng)域有一定優(yōu)勢，例如在A(yíng)CE回采時(shí)，我們會(huì )做主動(dòng)喚醒，有固定的時(shí)間窗口使回采算法更可靠，時(shí)間不固定時(shí)回采數據不及時(shí)，RTOS可對時(shí)間窗口做極大保證。

上圖是通用方案啟動(dòng)速度對比。我們可以看出系統分為Boot、OS、APP啟動(dòng)三個(gè)層面。從三個(gè)層面整體來(lái)看，Linux系統啟動(dòng)需要10秒左右，而使用RTOS方案啟動(dòng)時(shí)間只有一兩秒。

如上圖，我們從四個(gè)方面做了對比。如大家所知，Linux所需的RAM、Flash是比較高的。ARM cortex-A方案是主流高端方案需要32MB RAM 和64MB Flash 的消耗。據我們統計，遷移 RTOS 方案 后可做到2MB RAM 和 4MB Flash 左右的消耗。由于 RTOS 系統比較輕巧，我們可以使用更小的RAM、Flash 芯片。

除了以上優(yōu)勢，RTOS也有生態(tài)劣勢。智能音箱的操作系統更需要涉及到網(wǎng)絡(luò )、音頻相關(guān)的內容。Linux系統有成熟穩定的網(wǎng)絡(luò )框架、音頻子系統以及ffmpeg、Curl等開(kāi)源軟件。RTOS調度器則更多的使用了輕量級網(wǎng)絡(luò )協(xié)議棧，在音頻方面比較空缺，公司各有私有的方案，成本比較高。

我們使用RTOS研發(fā)音頻播放系統鑒于成本趨勢、系統資源問(wèn)題和開(kāi)發(fā)成本的綜合考慮，希望能完成一套比較完整成熟的音頻系統。

RT-Thread 網(wǎng)絡(luò )音頻播放器設計的迭代

如上圖是我們第一版音頻播放器方案框架。早期設計這一款播放器，沒(méi)有考慮網(wǎng)絡(luò )播放的相關(guān)的功能。這版邏輯比較簡(jiǎn)單：獲取音頻數據后直接做解碼，解碼過(guò)程是一個(gè)循環(huán)邏輯，單線(xiàn)程等待外部響應事件，包括seek事件、暫?；謴褪录?、停止事件完成播放器邏輯，最后將解析出的數據寫(xiě)入底層音頻驅動(dòng)。

由于第一版不滿(mǎn)足網(wǎng)絡(luò )播放的市場(chǎng)需求，我們將網(wǎng)絡(luò )組件、網(wǎng)絡(luò )功能添加到了系統中。如上圖中紅色邏輯處理部分。在這部分我們對框架思路做了修改，將文件、網(wǎng)絡(luò )資源放到同一層，選擇本地或網(wǎng)絡(luò )下載音頻資源，整體呈單線(xiàn)程模式。無(wú)論打開(kāi)的URL資源是本地資源還是網(wǎng)絡(luò )資源，都是獲得資源后做解碼播放 。

這版播放器隨著(zhù)在項目中越來(lái)越多的使用，逐漸的出現了很多噪音卡頓拖慢等問(wèn)題。如上圖是我們PCM項目回采得出的數據分析結果。我們在播放音頻出現了短暫噪音之后繼續播放的情況，后期多方面分析發(fā)現，這是由于網(wǎng)絡(luò )情況不穩定，解碼器短暫接收不到數據造成的。

如上圖所示網(wǎng)絡(luò )不可靠的原因有多種，很多網(wǎng)絡(luò )不穩定是網(wǎng)絡(luò )硬件造成的波動(dòng)，軟件層面是無(wú)法完全避免的，我們只能通過(guò)軟件算法和思路減少這些問(wèn)題造成的影響。

如上圖是我們第三版改進(jìn)后的播放器框架圖。左側是一樣的，依然是獲取數據進(jìn)行解碼，唯一不同的是我會(huì )從網(wǎng)絡(luò )緩存區獲取數據。啟動(dòng)播放后，我們會(huì )啟動(dòng)一個(gè)新線(xiàn)程將本地數據或網(wǎng)絡(luò )音頻寫(xiě)入緩存區，將下載與解碼器分離。只要緩存區有數據，解碼播放便不會(huì )出現卡頓。

我們采用了帶RTOS 喚醒調度機制且具有水位線(xiàn)管理的 pipe 作為第三版的音頻緩沖區 。例如我們設置了一個(gè)512KB的緩存區，通過(guò)HTTP連接下載數據。如果緩存區中沒(méi)有數據，我們可以簡(jiǎn)單認為下載與解碼同時(shí)進(jìn)行的。解碼時(shí)緩存區沒(méi)有數據時(shí)會(huì )等待直到音頻數據高于水位線(xiàn)。水位線(xiàn)即可開(kāi)始解碼的最低緩存數據量。我們做了一個(gè)可動(dòng)態(tài)調節的水位線(xiàn)機制。

改進(jìn)過(guò)后，我們做了一個(gè)測試。如上圖左側是我們的測試環(huán)境數據。V2版本中，理論上音樂(lè )碼率大于1411kbps時(shí)才支持播放。而V3版本中，當下載速度大于播放速度時(shí)會(huì )導致水位上漲，一定會(huì )出現高于水位線(xiàn)情況。當網(wǎng)絡(luò )出現卡頓時(shí)，緩存數據是高于水位線(xiàn)的，解碼器依然可以拿到數據。

在另一種測試環(huán)境時(shí)，當下載速度一直低于播放速度。這是一種極端情況，下載達不到規定碼率，無(wú)論如何播放都絕對不會(huì )流暢。V2版本中音頻會(huì )一直間隔卡頓導致用戶(hù)無(wú)法聽(tīng)清內容。在水位線(xiàn)機制中，當碼率較低，緩存不夠時(shí)是不會(huì )發(fā)出聲音的，會(huì )有一秒的緩存時(shí)間，緩存過(guò)后播放的聲音是較長(cháng)時(shí)間連續的。，這樣我們能夠提升一定會(huì )卡頓情況下的用戶(hù)體驗，讓在非?？D的網(wǎng)絡(luò )情況下音頻不再發(fā)出刺耳的噪音。

有時(shí)我們會(huì )播放一些相聲、新聞等實(shí)時(shí)音頻電臺流內容。和音樂(lè )文件有一些不同，這時(shí)會(huì )出現推送流碼率和播放流碼率相同的情況。

這種情況的解決涉及到變速不變調算法的使用，即我們會(huì )改變語(yǔ)音播放速度而不改變語(yǔ)義語(yǔ)調，改變較小時(shí)人耳不會(huì )聽(tīng)到差別。如上圖我們做了測試。當下載碼率與播放碼率相同時(shí)，我們通過(guò)變速不變調算法降低音頻的播放碼率，下載速度會(huì )始終大于播放速度。如圖中所示，雖然我們會(huì )進(jìn)行緩存，但是由于下載速度較小，水位線(xiàn)漲不上去，依然會(huì )出現一定卡頓。經(jīng)處理后，下載速度大于播放速度后，水位線(xiàn)會(huì )持續上漲，開(kāi)始播放后便可以降低出現卡頓的情況。

基于以上，我們完成了第四版的改進(jìn)。我們在寫(xiě)入底層播放驅動(dòng)前做對每一幀做變速不變調算法處理，當然這是可以選擇開(kāi)啟的功能。

除了可以做變速不變調處理，我們還可以在相同位置EQ算法均衡器等其它處理，實(shí)現流行音樂(lè )音效、超低音音效等效果。

于是我們又做了一次改進(jìn)。我們將變速不變調做了剝離，以插件的形式動(dòng)態(tài)選擇不同音效。

在智能音箱領(lǐng)域，客戶(hù)會(huì )使用多種容器、協(xié)議以及編碼格式。我們需要支持多種組合。

我們在原基礎上做了改進(jìn)，改進(jìn)點(diǎn)如上圖紅色部分所示。在之前版本中，我們會(huì )將數據直接下載緩存到緩存區進(jìn)行解碼。改進(jìn)后，我們將解碼和解容器進(jìn)行分離，在下載中加入了解容器，播放過(guò)程中解碼。解容器以插件形式接入系統，在播放過(guò)程中探測它的格式，選用合適的容器解碼格式。在這個(gè)過(guò)程中，不僅可以實(shí)現了多格式容器解碼，也實(shí)現了多協(xié)議解碼。我們將下載線(xiàn)程進(jìn)行分類(lèi)，針對不同協(xié)議做下載邏輯。將容器、協(xié)議、解碼器剝離后，播放器框架可實(shí)現多種組合應用場(chǎng)景。

混音框架設計

接下來(lái)我將介紹智能音箱設計過(guò)程中遇到的另一個(gè)重要問(wèn)題。如上圖左側部分，音箱服務(wù)器推送了一個(gè)音頻，在播放過(guò)程中突然需要播放提示音，通常我們需要將音頻暫停播放，插入提示音，播放完成后音頻恢復播放。在這種情況下，設備需要維護播放狀態(tài)的。如圖中原始音頻是44K，采樣率是16K，中間有采樣率切換的過(guò)程。切換采樣率的過(guò)程中，需要注意它的實(shí)時(shí)性，因為我們控制內部芯片會(huì )產(chǎn)生一定時(shí)延。另一個(gè)就是pop音問(wèn)題，當還有音頻在播放時(shí)，切換采樣率會(huì )有噪音出現。對此，我們做出了部分改進(jìn)，采用混音的思路：將原音頻音量降低，再采用混音的方式將提示音混入，提示音播放完成后恢復音頻音量。這種思路不需要考慮播放器播放狀態(tài)的維護，而且兩路音頻完全獨立，開(kāi)發(fā)者邏輯代碼編寫(xiě)也清晰簡(jiǎn)單。

我們在做這個(gè)方案時(shí)評估了Linux下的一個(gè)成熟算法。算法采用了線(xiàn)性重采樣算法。如上圖，它的庫里有五種模式，默認使用最低模式。我們使用ARM-CotexM4芯片做了測試，發(fā)現最多模式會(huì )占用百分之八十CPU。

libsamplerate算法輸入的數據是浮點(diǎn)類(lèi)型，使用此算法先將數據切為單精度浮點(diǎn)數，內部使用雙精度浮點(diǎn)數做計算采樣以確保采樣效果。如圖中48K音頻采樣耗費了115%CPU，重采樣過(guò)程花費三百多秒。我們對此做了改進(jìn)。我們對輸入參數使用整形定點(diǎn)算法，這時(shí)占用CPU降到了79%。我們又將內部雙精度浮點(diǎn)數強制降為單精度后，CPU占用率降到了49.5%。最終，我們做成了全整形數，這時(shí)CPU占用只有3.8%。另外，由于重采樣算法由C語(yǔ)言寫(xiě)成，我們從匯編層面對它做了優(yōu)化，之前的操作造成了采樣效果變差，通過(guò)匯編優(yōu)化將32位整型數改為了64位，整體效果雖不及浮點(diǎn)數，但整體效果提升了很多。

市面上主流混音算法模型有幾種，第一種是兩個(gè)聲道數據直接加和，當某一通道的數據幅度較大時(shí)混音后任意出現音頻數據溢出，從而音頻失真。第二種是加和后再除以音道數防止溢出，這樣會(huì )造成音道內音量衰減，并且音軌越多衰減越多。還有一種是加和箝位，即相加超過(guò)最大值時(shí)進(jìn)行限幅，這樣音頻也會(huì )失真。另外還有飽和處理、歸一化處理等?？紤]到RTOS 方案應用場(chǎng)景是一個(gè)音軌音量高一個(gè)音量稍低，我們并需要兩個(gè)聲音同時(shí)聽(tīng)清，我們只需要保證一個(gè)音軌的質(zhì)量。最終我們選擇了圖中第二種算法。雖然會(huì )產(chǎn)生一些衰減，但是在這個(gè)場(chǎng)景下只保證兩個(gè)音道中一個(gè)聲音清晰，衰減是可以忽略的。但是其它算法可能會(huì )出現失真，這是不能接受的。這種方案在實(shí)際應用中效果很好的。

上圖是我們測試結果。圖中是一幀數據、20毫秒的窗口，我們做了重采樣混音算法。優(yōu)化過(guò)后，主音軌重采樣耗了大概1.288毫秒，副音軌耗了1.296毫秒，混音用時(shí)1.281毫秒，在A(yíng)RM9 120MHZ的系統中耗費了大概20%的CPU消耗。