超低功耗解決方案如何賦能Always-on語音交互系統(tǒng)

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

消費者越來越需要可以隨時通過語音控制的產品，可以與數字世界更加安全的和自然的交互。

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

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

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

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

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

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

SPOT by Amibiq

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

Adaptive ZPL by Vesper

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

Audio Weaver by DSP Concept

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

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

需要Always-on語音交互的典型應用 - 

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

高功耗

待機時間

不可靠的互聯網鏈接

產品形態(tài)和結構設計限制

環(huán)境因素限制

便攜語音控制設備的硬件選型 - 

麥克風陣列

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

關于麥克風選型 - 

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

音頻處理器的選型 - 

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

比如Apollo 2和Apollo 3 Blue - 

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

語音驅動編寫產品的軟件和算法 - 

基本的算法結構包括 - 

Sound Detector

Noise reduction and filtering

Beamforming

Acoustic Echo Canceling

Wake-word detecion

Adaptive Interference Canceler

Local Command Set Recognition

Real-word Products

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

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

Algorithm Tuning算法調教

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

Detection/Wake Threshold

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

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

Noise Reduction/Canceling

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

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

Beamformer Beamwidth

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

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

Wake/Sleep Strategies

確保產品省點的方法之一是盡可能的使產品處于休眠狀態(tài)，當然更需要的是平衡，如果過于快速的讓設備進入休眠狀態(tài)，可能會無法捕捉用戶在喚醒詞激活后的語音命令。用戶不得已要再次說出喚醒詞，這樣會讓人相當的抓狂。但是如果讓設備進入休眠狀態(tài)過慢，又會造成不必要的電量的消耗。

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

關于超低功耗解決方案如何賦能Always-on語音交互系統(tǒng)問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業(yè)資訊頻道了解更多相關知識。