作者：Bougas Pavlos， Iliopoulos Marios

引言

最初，電視、機頂盒和空調等電器僅需少量控制功能［1］。在大多數情況下，開/關按鈕、幾個選擇按鈕和兩組增加/減少控制足以完全控制您的設備。

但隨著設備支持的功能增加，用戶使用的命令和配置選項也隨之增加。然而，用戶仍希望只用一個遙控器來管理所有功能。為了解決這個問題，工程師們開始整合更復雜的用戶界面（UI）。分層菜單出現在電視屏幕上，而越來越多的按鈕被填充到遙控器中，以便用戶調用和瀏覽菜單。

今天的重要趨勢是讓設備更“智能”。智能設備可以連接到其他設備和互聯網，來提供更多功能和服務。使用菜單瀏覽，并用遙控器上的小按鈕鍵輸入一大字符串是不切實際的，也不是個愉快的體驗。

在本文中，我們將討論如何使用語音命令來提供更好的用戶體驗。我們特別研究了使用Dialog基于DA14585的高級語音遙控參考設計，通過藍牙低功耗（BLE）實現語音命令。

圖1較大的 QWERTY遙控器

用語音作為命令界面

語音是一個非常強大和直觀的界面。一個簡單的短語可以包含足夠的信息來描述非常復雜的命令。然而，在嘈雜的環境中捕捉短語并提取有實際意義的信息（通常以字符串的形式），這在技術上是一個挑戰。幸運的是，產生這個需求的源頭，即智能設備與互聯網的連接，也為這一復雜問題提供了解決方案。設備現在可以訪問云計算，并且可以受益于最先進的語音到文本識別引擎，如Nuance Communications、微軟、谷歌、亞馬遜等公司提供的技術。如今，基于云的語音識別服務足以提供非常好的用戶體驗。

我們為什么還需要遙控器呢？

其實，不斷監聽語音命令的解決方案很早就開發出來了，設備可以不斷地收聽周圍的聲音并搜索命令。但是，背景噪音和用戶與麥克風的距離問題，使得難以正確識別信息。此外，設備和云服務之間交換的數據量非常巨大，語音識別引擎面臨大量的請求，其中大部分是不相關的。環境聲音的不斷記錄也帶來了嚴重的安全和隱私隱患。

我們需要一種觸發器，一般通過按鈕、手勢或可識別的單詞或短語來實現。這種解決方案適用于用戶和設備距離很近，例如智能手機。但要在智能電視、機頂盒和用戶離設備較遠的其他應用中，正確識別觸發信號并提供良好的用戶體驗就要困難很多。麥克風需要靠近用戶，不是有遙控器嘛。那么將麥克風嵌入遙控器就再自然不過了。

量化語音識別要求

簡單來說，語音命令功能的挑戰可以表述為：“捕獲‘足夠’的高質量語音記錄，將其發送到語音識別引擎，然后處理文本結果以得出用戶的命令”。這個短語包含兩組基本要求。首先是需要觸發器。實際上，需要兩個觸發器：第一個指示命令的開始，第二個指示結束。

第二組要求與音頻信號本身有關。語音記錄應采用適合引擎處理的格式進行編碼，而且質量要“足夠”好。質量“足夠”好怎么定義呢。安卓兼容性定義文檔［2］介紹了有關音頻捕獲質量指標的一些想法。

頻率響應應該在100 Hz到4000 Hz的語音頻譜上幾乎保持平坦（+/- 3 dB）。這是描述窄帶語音信號的眾所周知的規范。關于麥克風產生的信號電平，安卓兼容性指南定義了聲功率級-RMS圖中的單點，以及線性跟蹤聲功率級的范圍。

在1 kHz時聲壓級（SPL）為90 dB的聲音，對于16位PCM信號，應產生2500的RMS。這幾乎是16位有符號信號整體振幅范圍的10％。想要感覺一下SPL范圍的話，正常水平的電視機或典型的人類對話能在1米距離內產生60 dB SPL。相比之下，柴油貨車在10米距離處產生90 dB SPL。

圖2. 聲壓級示例

當然，我們不能期望用戶在隨時想使用語音命令的時候，都能把麥克風放在精確的位置并以特定的音量水平說話。鑒于PCM振幅水平可以線性追蹤變化，語音識別引擎可以在一系列不同的聲壓級工作。要求至少30 dB的范圍。從90 dB SPL點開始，麥克風應至少從-18 dB至+12 dB進行線性跟蹤; 因此在+72 dB SPL和+108 dB SPL之間。這相當于將麥克風放在離嘴0.8厘米至25厘米之間，并以正常強度說話。

圖3. PCM到SPL坐標圖

語音識別引擎似乎對非線性行為比較敏感。對于麥克風上90 dB SPL輸入電平的1 kHz正弦波，總諧波失真應小于1％。降噪處理、自動增益控制（如果存在）必須禁用。

其他要求

過去曾使用過無線音頻協議的人，通常比較懷疑使用面向數據的協議來傳輸語音命令，例如藍牙低功耗。

傳輸語音命令與傳輸實時音頻或人聲（如電話交談）略有不同。由于用戶不必回聽他們的聲音或保持對話，所以延遲要求可以放寬，因為固定的和一定范圍內的延遲是不可避免的。但是，數據丟失要求是很嚴格的，因為缺少音頻片段可能使語音識別引擎無法成功提取用戶的初始信息。當然機器可以要求您重復這條信息，但這不是人們想要的體驗。

構建語音命令遙控器

現在我們看看語音命令遙控器的架構，我們將按照通過系統的音頻信號的路徑來看。在這個過程中，我們將著眼于在實現經濟有效、功率效率高的語音遙控器時經常遇到的挑戰，以及可能的解決方法。

圖4. 典型的語音捕獲信號路徑

一切都從音頻捕獲子系統開始。這可以基于不貴的模擬麥克風和編解碼電路，或數字麥克風，將樣本數字化并根據已知的串行協議進行傳輸。

對于電池供電的系統（如語音命令遙控器），將功耗降到最低至關重要。因此，強烈建議對麥克風或外部編解碼器等外部元件的電源進行功率門控。

音頻采樣率必須至少為8k Samples / s以滿足4 kHz音頻帶寬要求。但是，每個采樣至少16位的16k Samples / s是更常規的選擇。采用16位采樣可確保足夠的聲壓級范圍，從而捕獲的音頻信號將包含足夠的信息，以便語音到文字的識別工作正常進行。

采樣音頻涉及中斷或某種形式的硬件 DMA，以獲取采樣并將其傳輸到緩沖區。該緩沖區需要將嚴格定時的音頻采樣與隨后的音頻處理解耦。對于低成本設備，音頻處理由服務應用程序的相同處理器處理，在某些情況下由BLE協議棧處理。因此，緩沖區的大小將取決于音頻處理模塊接入CPU、處理音頻數據并將其移至下一步所需的最大預期時間。典型的時間在幾毫秒內。對于16位16k Samples /s信號，每毫秒產生32個字節，160-200字節緩沖器一般足以允許5毫秒以內的處理時間。

音頻處理模塊實現簡單的音頻處理，并對音頻數據進行編碼以降低其總體速率。音頻處理包括非常基礎的濾波，如直流偏移消除或帶通濾波，和固定增益以優化音頻振幅。原始音頻數據為256 kbit / s，可以通過BLE進行有余量地流數據傳輸。為了降低速率并更好地利用帶寬，使用已知的音頻壓縮算法對音頻進行編碼。編碼器的選擇比較多樣，從簡單的固定速率有損編解碼器（如IMA-ADPCM），到復雜的處理密集型固定或可變速率算法（如OPUS）。簡單的編解碼器可以在MIPS容量較低的CPU上運行，但在相同的輸出比特率下，生成的音頻流質量較低。另一方面，復雜的算法可以提高編碼音頻流的質量，但需要較貴且耗電較多的CPU。

編碼器的輸出包含需要通過無線傳輸的最終有效載荷，并且需要一個額外的緩沖器來幫助均衡即時RF數據速率與編碼器的平均輸出速率。編碼器的輸出速率等于采樣音頻速率除以實現的壓縮比率。下面的表格顯示了Dialog的語音遙控器（Voice RCU）參考設計支持的典型原始和編碼音頻速率。

表1. 原始的和 IMADPCM 編碼的音頻

BLE是一種基于數據包的協議，在特定時間點交換數據包，由定期連接間隔分隔開。如果干擾在會合點期間發生使數據包失真，則數據將在下一個數據包中重新傳輸。每個連接間隔都發生在不同的頻率通道中。通常，一個頻率范圍內會經常出現干擾信號，使多個連接事件失真并顯著降低帶寬。

BLE提供了一種叫做信道映射更新的機制來解決這個問題。主設備將檢測受影響的頻率范圍，并實施信道映射更新程序。在此之前，BLE連接可能會經歷RF數據速率的顯著下降。編碼器輸出端的緩沖區的大小應相應調整，以便能承受此類事件。大小調整可以使用超安全方法，例如緩沖完整5秒鐘信息需要40k字節，或者以一半的速率進行5秒鐘的緩沖，而不丟失任何數據，這需要20k字節的緩沖。考慮市場上可用的設備，這是一個非常難以滿足的要求。大多數設備的整個協議棧和應用程序都只有20 - 40 kbytes的總可用RAM。這個資源不能浪費在單個緩沖區上。需要注意是，緩沖區的大小與編碼器輸出速率和確保數據不丟失的時間成正比。

市場上已經提出了很多種技術，可以單獨使用或組合使用來解決這個問題，而無需很大的緩沖區。在流傳輸音頻樣本時增加RF輸出功率，以盡可能減少干擾；快速微調信道映射；使用更復雜的編碼器來降低所需的RF數據速率，或者甚至在檢測到明顯的RF帶寬下降時動態地降低質量。每種技術都會以犧牲某些其他資源（如能耗、CPU占用或音頻質量）的代價來處理問題，而不是使用更多的RAM。

根據所使用的編碼器算法，可以將數據存儲為連續流或預定義了長度的數據包列表。為了更好地利用BLE帶寬，最好將數據視為未經編碼器分包的數據流。BLE傳輸的無損性質確保我們始終能夠在遙控器上重建我們的初始數據流。多個BLE連接參數 -- 連接間隔、ATT_MTU大小、數據信道PDU大小和連接事件長度 -- 會影響BLE數據包的理論最佳大小的選擇。在運行時，實際的錯誤率可能需要進一步優化數據包大小。由于消除了遙控器響應和數據包之間間隙所需的時間，使用大一些的數據PDU可以有效地使有效數據速率加倍。另一方面，單個數據包的傳輸時間延長，增加了在傳輸數據包期間發生錯誤的可能性以及重傳成本。在嚴重無線污染的環境中，使用小一點的數據PDU可能會比使用已溝通的最大協議數據單元更有效。

所有這些要求決定了智能模塊的出現，智能模塊將數據從編碼流中提取出來，根據連接特性打包數據，并將其推入BLE協議棧，同時監測實際BLE數據速率和錯誤率。打包器還應具有某種形式的仲裁和流量控制，以避免過多數據涌入BLE協議棧，并為其他應用保留足夠的帶寬，以便在音頻傳輸過程中使用BLE進行數據交換，以確保設備不會無響應。

Dialog先進語音遙控解決方案

為了讓設計人員能夠評估功能完整的語音命令遙控器的性能，Dialog提供了基于單個DA14585 藍牙低功耗（BLE）SoC的先進語音遙控參考設計。該設計不僅支持語音，還支持一系列附加功能，如無線鼠標、觸摸板、紅外線以及按鍵，這些功能都存在于現代遙控器設計中，為用戶提供更自然的方式與終端設備進行交互并瀏覽菜單和結果。

圖5. Dialog 語音遙控器開發套件

第二代參考設計包括整個軟件架構的重要變化，更加模塊化、更易于適應最終產品要求。所有的功能都被組織成模塊，具有平臺相關和獨立的部分。這些模塊連接到驅動程序，用于DA14585內部外設或為Dialog先進語音遙控開發板選擇的外部元件。

音頻路徑是根據前面介紹的原則構建的。

圖6. Dialog語音遙控解決方案的系統架構

為了提高音頻質量，該設計采用了數字麥克風。對于成本敏感型應用，PDM麥克風比I2S / PCM會更適合。DA14585的集成PDM-PCM轉換器將高頻PDM信號轉換為24位音頻PCM采樣，并通過專用DMA信道將其傳送至存儲器緩沖區。

M0 CPU執行音頻處理和流傳輸模塊。從主循環中，調用一個預處理模塊來應用直流阻斷和24位至16位的轉換。如果需要，下采樣單元可以將音頻采樣率從16k Samples / s減少到8k Samples / s。音頻預處理單元的結果被饋送到IMA ADPCM編碼器。根據配置的不同，編碼器會為每個16位音頻采樣生成一個4位或3位采樣。

圖7. Dialog語音遙控解決方案音頻路徑

作為設計選擇，該參考設計支持自適應音頻速率機制，以防止可能的緩沖區欠載。音頻采樣的采樣率和/或IMA ADPCM編碼器的配置可隨時更改，從而可以在不同的輸出速率之間切換。為了支持這種機制，已經開發了帶內信令機制。編碼器的輸出和帶內信令共享同一個的數據流緩沖區。

打包器模塊收集來自數據流緩沖區的數據，并高效地將它們推入協議棧，同時盡量不溢出。除了考慮連接參數外，打包器還密切監測錯誤率和瞬時可用帶寬。這有助于其在自適應音頻速率機制啟用時，做出是否降低或提高音頻質量的決定。

所有策略，如使用固定或自適應音頻速率，音頻開始和停止的方式，均由用戶或遠程設備控制。單獨的緩沖區大小都是配置選項，因為根據最終應用的不同，可能適合不同的用戶體驗。

結論

將設備連接到互聯網的能力，與現代基于云的語音識別服務相結合，實現了強大的新用戶界面 - 語音命令。智能手機、智能電視和機頂盒已經在使用語音命令。通過將低成本的麥克風集成到BLE連接的外圍設備中，用戶的語音識別體驗可以大大增強。從遙控器、智能手表和可穿戴設備收集的命令，通過智能設備傳輸到云中的語音識別引擎，可以控制智能設備本身以及與智能設備相連的外圍設備或由語音助理控制的其他設備。