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

文 / 黃天翔

整理 / LiveVideoStack

智能音箱現(xiàn)狀

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

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

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

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

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

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

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

Linux向RTOS方案遷移分析

?

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

?

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

?

如上圖，我們從四個(gè)方面做了對(duì)比。如大家所知，Linux所需的RAM、Flash是比較高的。ARM cortex-A方案是主流高端方案需要32MB RAM 和64MB Flash 的消耗。據(jù)我們統(tǒng)計(jì)，遷移 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)度器則更多的使用了輕量級(jí)網(wǎng)絡(luò)協(xié)議棧，在音頻方面比較空缺，公司各有私有的方案，成本比較高。

?

?

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

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

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

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

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

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

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

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

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

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

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

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

基于以上，我們完成了第四版的改進(jìn)。我們?cè)趯懭氲讓硬シ膨?qū)動(dòng)前做對(duì)每一幀做變速不變調(diào)算法處理，當(dāng)然這是可以選擇開啟的功能。

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

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

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

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

混音框架設(shè)計(jì)

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

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

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

?

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

?

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

LiveVideoStackCon 2020

上海/北京/舊金山 講師招募

2020年LiveVideoStackCon將持續(xù)迭代，LiveVideoStackCon將分別在上海（6月13-14日），北京（9月11-12日）和舊金山（11月）舉行。歡迎將你的技術(shù)實(shí)踐、踩坑與填坑經(jīng)歷、技術(shù)與商業(yè)創(chuàng)業(yè)的思考分享出來，獨(dú)樂不如眾樂。請(qǐng)將個(gè)人資料和話題信息郵件到 speaker@livevideostack.com 或點(diǎn)擊【閱讀原文】了解成為LiveVideoStackCon講師的權(quán)益與義務(wù)，我們會(huì)在48小時(shí)內(nèi)回復(fù)。

總結(jié)

以上是生活随笔為你收集整理的RT-Thread智能音箱音频应用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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