超低功耗解決方案如何賦能Always-on語音交互系統(tǒng)，針對這個(gè)問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

消費(fèi)者越來越需要可以隨時(shí)通過語音控制的產(chǎn)品，可以與數(shù)字世界更加安全的和自然的交互。

特別是隨著COVID-19在全球的肆虐，也在深刻改變著人們的生活習(xí)慣 - 更加傾向于避免物理的接觸，而傾向于不用手的語音交互方式。

人們對公眾場合各種接觸界面病毒傳播的擔(dān)憂，正在驅(qū)動(dòng)語音交互更加快速的進(jìn)入到包括智慧城市，智能家居，以及各種工業(yè)應(yīng)用中去。

直到先進(jìn)的能量效率(power-efficient)更高的硬件和軟件技術(shù)的發(fā)展，各種編寫的和需要電池驅(qū)動(dòng)（battery powered products）產(chǎn)品實(shí)現(xiàn)隨時(shí)的語音監(jiān)聽和交互才成為了可能。

以下內(nèi)容來自于Ambiq+Vesper+DSPC聯(lián)合發(fā)布的白皮書，共同探討了技術(shù)，應(yīng)用的突破，如何使超低功耗的Always-on語音交互產(chǎn)品成為了可能。

以前的一些語音交互產(chǎn)品，需要以案件的方式(Push-to-talk)喚醒設(shè)備，而不是通過喚醒詞。而在Always-on語音交互系統(tǒng)中，比如Amazon Echo, Apple HomePod, Google Home等已經(jīng)采用喚醒詞環(huán)形的方式，如Alexa和OK Google。

包括Sensory, Ambiq, Vesper, DSPG正在協(xié)力(in tandem)力求在提升語音交互體驗(yàn)的同時(shí)，降低系統(tǒng)功耗，如Ambiq的微控制器其功耗僅為其他傳統(tǒng)處理器的十分之一，而Vesper的麥克風(fēng)也將總體系統(tǒng)功耗進(jìn)一步降低為傳統(tǒng)系統(tǒng)的十分之一。

SPOTbyAmibiq

得益于其SPOT(Sub-threshold Power Optimized Technology)，Ambiq的MCU和SoCs僅需傳統(tǒng)音頻處理器的十分之一的安培，非常適合于超低功耗的聽力設(shè)備，穿戴設(shè)備和其他移動(dòng)設(shè)備(hearables, wearables, and other mobile applications)。

Adaptive ZPL by Vesper

Vesper麥克風(fēng)提供前所未有的ZPL引擎，可以實(shí)時(shí)監(jiān)聽音頻信號水平并隨后激活音頻處理器處理特定的音頻(activate hibernating audio processor in response to a specific audio event)，從而將系統(tǒng)總體功耗進(jìn)一步減低90%。

Audio Weaver by DSP Concept

TalkTo音頻前端處理算法及Audio Weaver平臺可以通過簡單的拖拽的方式(drag-and-drop)界面開發(fā)先進(jìn)的基于嵌入式處理器的語音相關(guān)設(shè)計(jì)。

Sensory可提供其中的語音喚醒詞識別引擎和喚醒詞模型。

需要Always-on語音交互的典型應(yīng)用-

Always-on語音控制便攜設(shè)備所面臨的技術(shù)挑戰(zhàn) -

高功耗

電池驅(qū)動(dòng)的便攜設(shè)備由于尺寸的限制，不能采用較大容量的電池，同時(shí)處理器有需要對語音喚醒詞做出即時(shí)反應(yīng)(ultra-responsive)，因此需要至少一個(gè)麥克風(fēng)處于時(shí)刻監(jiān)聽狀態(tài)。

同時(shí)由于電池驅(qū)動(dòng)的便攜設(shè)備由于產(chǎn)品形態(tài)和產(chǎn)品尺寸限制，需要依靠高度集成的SOC處理器，因此很難通過關(guān)閉一部分功能來降低功耗。

待機(jī)時(shí)間

廠商在不斷提升產(chǎn)品單次充電使用時(shí)長上面臨著持續(xù)的競爭和挑戰(zhàn)，如一般的TWS耳機(jī)均已經(jīng)實(shí)現(xiàn)單次充電可使用5個(gè)小時(shí)以上，結(jié)合電池倉則可以方便的延長產(chǎn)品的使用壽命。

不可靠的互聯(lián)網(wǎng)鏈接

穿戴產(chǎn)品通常作為手機(jī)的附件，通過低功耗藍(lán)牙與手機(jī)通信，而網(wǎng)絡(luò)在很多地方是不可靠的。因此設(shè)備本身，需要具備一定的小單詞量語音識別的處理能力。(process a small vocabulary of voice commands )

產(chǎn)品形態(tài)和結(jié)構(gòu)設(shè)計(jì)限制

環(huán)境因素限制

語音驅(qū)動(dòng)產(chǎn)品的麥克風(fēng)需要滿足在復(fù)雜環(huán)境情況下的正常使用，如IPX5和IPX7。

便攜語音控制設(shè)備的硬件選型 -

麥克風(fēng)陣列

環(huán)形陣列，比如應(yīng)用于智能音箱的產(chǎn)品。常用于家庭電器和TV的麥克風(fēng)陣列，但是受限于不同產(chǎn)品的空間布局，如間距10到20毫米的要求，如TWS耳機(jī)僅僅可能支持兩個(gè)麥克風(fēng)的布局。

關(guān)于麥克風(fēng)選型 -

比如Vesper的VM3011在"wake on sound“模式下，僅需消耗10微安的電流，通過超低功耗的模擬電路，可以監(jiān)聽和給你總環(huán)境聲水平，僅僅在監(jiān)聽識別到高于背景噪音的聲音后才會(huì)激活后端系統(tǒng)，可以使系統(tǒng)在81%到92%時(shí)間內(nèi)處于睡眠狀態(tài)，從而可以極大的降低系統(tǒng)功耗。

音頻處理器的選型 -

Ambiq的SPOT技術(shù)加持的Apollo處理器僅消耗傳統(tǒng)音頻處理器十分之一的電池能量。

比如Apollo 2和Apollo 3 Blue -

Apollo 3更是將功耗進(jìn)一步降低(6微安每MHz)，將主頻進(jìn)一步提升，支持多麥克風(fēng)信號的處理。

語音驅(qū)動(dòng)編寫產(chǎn)品的軟件和算法 -

基本的算法結(jié)構(gòu)包括 -

Sound Detector

如Vesper的ZPL自適應(yīng)麥克風(fēng)當(dāng)聲音超過一定閾值之后，如用戶呼叫喚醒詞，麥克風(fēng)就會(huì)識別并發(fā)出信號激活系統(tǒng)，且整個(gè)的反應(yīng)時(shí)間不超過200微秒。

Noise reduction and filtering

如Vesper ZPL可以過濾掉環(huán)境噪聲

Beamforming

通過處理多個(gè)麥克風(fēng)信號來獲取聲音的指向性信息，只接受特定方向的聲音型號，而拒絕來自其他方向的聲音信號。對于諸如耳機(jī)或者是車載環(huán)境下的麥克風(fēng)陣列，其用戶聲源的方向性是確定的（the direction of the user's voice relative to the microphone array is known)，而對于其他設(shè)備如智能音箱，遙控器，安裝在墻上的家庭設(shè)備自動(dòng)語音控制器等等，聲源信息是不確定性的。

Acoustic Echo Canceling

回音消除會(huì)拒絕掉來自設(shè)備自身的聲音，這樣可以更清楚地提取用戶的聲音，盡可能地降低用戶聲音的回路畸變(distortion)，對于獲得更好的AEC性能是非常重要的。DSPC的立體聲AEC算法，可以消除高達(dá)35dB的回聲。

Wake-worddetecion

當(dāng)設(shè)備檢測到聲音激活處理單元，會(huì)將音頻錄音與預(yù)先存儲的喚醒詞數(shù)字文件進(jìn)行比對，如果其波形與存儲模型非常接近，那么設(shè)備將開始接收語音命令信號。

不同于其他的便攜設(shè)備，對于智能音箱只需要檢測喚醒就可以了，而將接下來的語音命令識別上傳至云端完成(offload other voice recognition tasks to an external cloud)。通常喚醒詞識別由設(shè)備端完成，但如AMAZON也可在云端執(zhí)行進(jìn)一步的更準(zhǔn)確的喚醒詞識別(enable additional wake word checks in cloud)。

Adaptive Interference Canceler

Local Command Set Recognition

由于很多的便攜設(shè)備實(shí)際上并沒有連接到互聯(lián)網(wǎng)云端，因此需要在設(shè)備端自己完成包括喚醒詞和語音命令在內(nèi)的語音識別和交互，而這些本地語音命令所執(zhí)行的功能通常會(huì)非常有限，如PLAY, PAUSE, SKIP TRACK, REPEAT, ANSWER CALL等等。

其他通過藍(lán)牙或WIFI連接到手機(jī)的穿戴類產(chǎn)品如耳機(jī)，則可以在手機(jī)端完成語音命令的識別。

Real-word Products

在真實(shí)的產(chǎn)品環(huán)境中，如運(yùn)行于Ambiq Apollo 3和DSP Concept TalkTo算法的遙控器，在一米的測試距離，同時(shí)兩米開外有TV以62-78dB播放音頻，而語音的播放聲強(qiáng)為65dB，其獲得的SNR如下-

單麥克風(fēng)需要之上3dB的SNR才可以達(dá)到喚醒詞識別率超過80%，2-Mic波束成形加上單信道噪音消除(SCNR, Single Channel Noise Reduction)算法與AIC一樣僅需要0dB SNR。

隨著SNR逐步惡化，AIC可獲得更加的性能，如-6dB SNR下約10%的性能替提升。

Algorithm Tuning算法調(diào)教

以上的算法相當(dāng)?shù)膹?fù)雜，需要針對具體產(chǎn)品，如便攜穿戴產(chǎn)品與家居產(chǎn)品，其使用環(huán)境和使用場景相當(dāng)不同，需要做出相應(yīng)的調(diào)整(be adjusted to suit the application, where the environment and use patterns are quite different)。以下為需要調(diào)教的算法功能以便獲取最優(yōu)的語音識別精度(optimum voice recognition accuracy)。

Detection/Wake Threshold

如何正確的平衡喚醒率和誤喚醒率需要在不同的use case綜合考慮。比如遙控器通常在1米左右的操作距離，一般需要把喚醒靈敏度閾值設(shè)置的較低些，而穿戴產(chǎn)品一般則需要設(shè)定的較高些以避免誤喚醒。

對于其他的便攜設(shè)備來說，理想狀態(tài)是可以依據(jù)不同的噪音環(huán)境動(dòng)態(tài)調(diào)節(jié)家已補(bǔ)償(adjusted dynamically to compensate for varing level of ambient sounds)。

Noise Reduction/Canceling

設(shè)備需要針對不同應(yīng)用的不同噪音類型進(jìn)行調(diào)校而實(shí)現(xiàn)降噪的功能。(be tuned to reject different types of noises depending on their application)。比如車載環(huán)境下的不同速度的路噪和引擎噪音相對來說是確定性的，因此相對容易的可以調(diào)校語音識別系統(tǒng)去除此類噪聲。

同時(shí)消噪算法也可以根據(jù)變化的環(huán)境而動(dòng)態(tài)的調(diào)整(funtions dynamically by adapting to the chaning environment)。

BeamformerBeamwidth

Beamwidth相對來說越緊的話，其對環(huán)境噪音的屏蔽就越好，但同時(shí)也會(huì)造成在用戶輕微移動(dòng)的時(shí)候容易發(fā)生無法提取用戶聲音的情況(beamwidth too tight causes the unit to reject the user's voice if the user moves slightly)。

對于耳機(jī)產(chǎn)品來說，用戶與產(chǎn)品麥克風(fēng)之間的相對位置是固定的，因此可以將Beamwidth設(shè)置的較為緊(tight)些，而對諸如遙控器產(chǎn)品或者是家用的控制面板(home automation panel)，Beamwidth應(yīng)設(shè)置的寬些(wider)以便在用戶移動(dòng)的時(shí)候，也可以拾取用戶的聲音。

Wake/Sleep Strategies

確保產(chǎn)品省點(diǎn)的方法之一是盡可能的使產(chǎn)品處于休眠狀態(tài)，當(dāng)然更需要的是平衡，如果過于快速的讓設(shè)備進(jìn)入休眠狀態(tài)，可能會(huì)無法捕捉用戶在喚醒詞激活后的語音命令。用戶不得已要再次說出喚醒詞，這樣會(huì)讓人相當(dāng)?shù)淖タ瘛５侨绻屧O(shè)備進(jìn)入休眠狀態(tài)過慢，又會(huì)造成不必要的電量的消耗。

其中語音識別引擎部分，可選用Sensory TrulyHandsFree -

總結(jié)

以上是生活随笔為你收集整理的超低功耗解决方案如何赋能Always-on语音交互系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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