BLE語音案例研究：在Google的語音搜索框架內(nèi)使用藍(lán)牙LE遙控器

Voice over BLE case study: Using bluetooth LE remote controller inside oolegg's Voice search framework 原文

第一部分 引言

雖然越來越多的新電視或STB連接到互聯(lián)網(wǎng)，但最終用戶體驗(yàn)不是很好，因?yàn)槠聊簧系逆I盤界面不切實(shí)際，需要用戶通過以令人煩惱的緩慢的速度移動光標(biāo)進(jìn)行鍵入?？赡艿慕鉀Q方案是使用語音識別來執(zhí)行各種智能電視功能，包括語言命令（zapp頻道，控制音量，打開各種應(yīng)用），搜索互聯(lián)網(wǎng)內(nèi)容，甚至在社交網(wǎng)絡(luò)服務(wù)上發(fā)布/分享評論。這個問題是公認(rèn)的，市場上可以找到帶有語音搜索功能的智能電視機(jī)遙控器。一個例子就是LG的“Magic Remote”遙控器品牌。然而，由于它們依賴于標(biāo)準(zhǔn)的BR/EDR藍(lán)牙技術(shù)，現(xiàn)有解決方案為最終用戶帶來了新的問題：高功耗和這些RC的電池壽命不可接受。更好的選擇將是藍(lán)牙LE，以低功耗設(shè)計(jì)的技術(shù)為主要目標(biāo)。

在第二節(jié)和第三節(jié)中，我們簡要介紹了標(biāo)準(zhǔn)藍(lán)牙和藍(lán)牙LE技術(shù)，以便提供足夠的背景信息來闡述BLE語音傳輸?shù)奶魬?zhàn)。在第四節(jié)制定問題陳述之后，在第五節(jié)中，我們提出了一個針對BLE語音用例的解決方案。最后，在最后兩節(jié)，我們提出驗(yàn)證結(jié)果并得出結(jié)論。

第二部分 藍(lán)牙和藍(lán)牙概述

藍(lán)牙是一種用于短距離數(shù)據(jù)交換的無線技術(shù)，使用2.4至2.485 GHz的無執(zhí)照工業(yè)，科學(xué)和醫(yī)療（ISM）頻段的無線電傳輸。由愛立信于1994年創(chuàng)立，藍(lán)牙最初是開發(fā)商作為無線替代已知的RS-232數(shù)據(jù)線的。它允許我們在設(shè)備之間無線地共享語音，數(shù)據(jù)，音樂，照片，視頻和其他信息。

藍(lán)牙低功耗（藍(lán)牙LE，BLE，作為Bluetooth Smart推廣）是2011年藍(lán)牙規(guī)范v4.0中引入的原始藍(lán)牙品牌的擴(kuò)展。BLE雖然被設(shè)想為擴(kuò)展，實(shí)際上是從頭開始設(shè)計(jì)的新技術(shù)，具有以下目標(biāo)：

  • 最低功率運(yùn)行
  • 最低可能的延遲

然而，由于設(shè)計(jì)限制，它必須重用盡可能多的藍(lán)牙RF頻譜和底層藍(lán)牙軟件棧。采用所提到的設(shè)計(jì)決定使得所謂的雙模式藍(lán)牙芯片的存在。這些芯片可以同時支持標(biāo)準(zhǔn)的v4.0藍(lán)牙應(yīng)用（BR/EDR設(shè)備）和新的LE應(yīng)用（LE設(shè)備）。圖1中示出了雙模設(shè)備的藍(lán)牙軟件棧。

圖1 雙模藍(lán)牙解決方案

第三部分 BLE架構(gòu)

BLE不太明顯但又重要的特征之一是它被設(shè)計(jì)為作為可擴(kuò)展框架來交換數(shù)據(jù)。與傳統(tǒng)藍(lán)牙相比，這是一個根本的區(qū)別，它專注于一組嚴(yán)格的用例。另一方面，BLE被設(shè)想為允許任何擁有想法和一堆數(shù)據(jù)的人都可以實(shí)現(xiàn)它，而不必太深入底層技術(shù)。這里重要的是要提到BLE不是為了支持高數(shù)據(jù)速率而設(shè)計(jì)的，而是專注于最低功耗傳遞小而不頻繁的數(shù)據(jù)位的?？罩袛?shù)據(jù)速率為1 Mbps，但應(yīng)用吞吐量取決于連接參數(shù)。通常為0.2 Mbps。BLE技術(shù)的全面覆蓋可以在[1]中找到。然而，在本文中，我們只定義了關(guān)鍵的BLE術(shù)語和概念，以形成問題陳述，并闡述了一個提出的解決方案。

通用訪問配置文件（Generic Access Profile，GAP）是確定兩個設(shè)備如何（或不能）彼此交互的基石。它提供了任何BLE實(shí)現(xiàn)必須遵循的框架，以允許設(shè)備發(fā)現(xiàn)彼此，廣播數(shù)據(jù)和建立連接。連接只是在預(yù)定義時間之間的設(shè)備之間的一系列數(shù)據(jù)交換。每個交換都稱為連接事件。以下三個連接參數(shù)是在建立連接期間由設(shè)備傳達(dá)的關(guān)鍵變量：連接間隔（connection interval，兩個連續(xù)連接事件之間的時間），該值范圍從7.5 ms到4 s）；從設(shè)備延遲（slave latency，從設(shè)備可以選擇跳過而不會有斷開連接的連接事件數(shù)）和連接監(jiān)視超時（connection supervision timeout，考慮連接丟失之前兩個接收到的有效數(shù)據(jù)包之間的最大時間）。

通用屬性配置文件（Generic Attribute Profile，GATT）詳細(xì)介紹了如何通過BLE連接交換數(shù)據(jù)。與GAP相反，它僅涉及實(shí)際的數(shù)據(jù)傳輸過程和格式。GATT還為所有基于GATT的配置文件提供了參考框架，涵蓋了精確的用例，并確保了來自不同供應(yīng)商的設(shè)備之間的互操作性。GATT了解的一個重要概念是服務(wù)器/客戶端關(guān)系。所有事務(wù)由主設(shè)備即GATT客戶端啟動，GATT客戶端接收從設(shè)備，即GATT服務(wù)器的響應(yīng)。BAT中的GATT事務(wù)基于稱為“配置文件”，“服務(wù)”和“特征”的高級嵌套對象，如下圖所示：

圖2 GATT配置文件，服務(wù)與特征之間的關(guān)系

特征是GATT事務(wù)中的最低層次的概念，封裝了單個數(shù)據(jù)點(diǎn)（盡管它可能包含相關(guān)數(shù)據(jù)的數(shù)組，例如來自3軸加速度計(jì)的XN/Z值等）。服務(wù)用于將數(shù)據(jù)分解為邏輯實(shí)體，并包含稱為特征的特定數(shù)據(jù)塊。服務(wù)可以具有一個或多個特征，并且每個服務(wù)通過稱為UUID的唯一數(shù)字ID將其自身與其他服務(wù)區(qū)分開來。配置文件是由Bluetooth SIG或外圍設(shè)備設(shè)計(jì)人員編譯的預(yù)定義的服務(wù)集合。例如，通過GATT配置文件（HOGP）的人機(jī)接口設(shè)備（HID）組合了HID服務(wù)，電池服務(wù)和設(shè)備信息服務(wù)。HID設(shè)備是人類用于控制計(jì)算機(jī)系統(tǒng)的操作的一種計(jì)算機(jī)設(shè)備。除了最典型的例子，如：摩絲，鍵盤，軌跡球和操縱桿，BLE遙控器也屬于HID組。正式通過的關(guān)于GATT的簡介的完整列表可以在[2]中找到。

第四部分 問題聲明

根據(jù)上一節(jié)提供的信息，我們可以確定BLE語音兩個問題：

  • 現(xiàn)在BLE沒有指定傳輸?shù)蛶捳Z音音頻數(shù)據(jù)的默認(rèn)方法。
  • 按照設(shè)計(jì)，BLE不支持高數(shù)據(jù)速率。對于通過BLE實(shí)現(xiàn)的任何自定義語音，我們必須了解應(yīng)用程序吞吐量的限制。

第五部分 語音實(shí)現(xiàn)

自4.3版（API 18級）以來，Android已經(jīng)引入了對BLE的內(nèi)置支持，現(xiàn)在提供了應(yīng)用程序可以用來發(fā)現(xiàn)設(shè)備，查詢服務(wù)和讀/寫特性的APls。盡管在Android BLE API之上開發(fā)用于低帶寬語音音頻數(shù)據(jù)傳輸?shù)亩ㄖ品?wù)是可能的，但它帶來了可移植性問題。對于BLE的整體Android API支持仍然是一個移動目標(biāo)，APls有望改變。因此，在本文中，我們提出了一種不同的，更通用的方法。這個想法是利用現(xiàn)有的HOGP配置文件，用于關(guān)鍵事件和語音流。HOGP設(shè)備上按鍵事件的數(shù)據(jù)流如下圖所示：

圖3 HOGP設(shè)備按鍵事件傳播在Android平臺上

重要的是強(qiáng)調(diào)藍(lán)色HOGP組件對關(guān)鍵事件類型和鍵事件數(shù)據(jù)有效負(fù)載是不可知的事實(shí)。所有事件都寫入內(nèi)核HID子系統(tǒng)。內(nèi)核HID子系統(tǒng)識別常規(guī)的按鍵事件，并將其進(jìn)一步傳播到內(nèi)核輸入框架。但是，HID不知道的關(guān)鍵事件不會被丟棄。事實(shí)上，所有的事件都在內(nèi)部排隊(duì)，并可以通過HID原始界面從用戶空間訪問。

這些事實(shí)為我們提供了足夠的動機(jī)，將語音流視為新的特殊類型的一系列離散的HOGP鍵事件。這種方法的關(guān)鍵優(yōu)點(diǎn)是我們不必為低帶寬語音數(shù)據(jù)實(shí)現(xiàn)新的BLE配置文件，也不需要擴(kuò)展現(xiàn)有的HOGP BLE配置文件。HOGP配置文件可以“按原樣”使用，作為語音有效載荷的虛擬代理，被視為一種新型的鍵事件。在這方面，我們可以提出BLE語音搜索實(shí)現(xiàn)，如下圖所示：

圖4 提出的語音流數(shù)據(jù)流

這個概念的實(shí)現(xiàn)只需要有兩個相對簡單的軟件組件，而沒有其他Android系統(tǒng)的修改。第一個組件（btvoiced）是一個自定義語音搜索守護(hù)程序，它從HID原始設(shè)備讀取pcm樣本，并將它們寫入第二個自定義組件，即捕獲設(shè)備ALSA驅(qū)動程序（snd_bt）。

語音流調(diào)制（Voice Stream Modulation，ADPCM）

ALSA捕獲設(shè)備是用于讀取語音輸入流的pcm樣本的Andorid語音搜索框架的標(biāo)準(zhǔn)接口。ALSA設(shè)備的捕獲格式由框架暗示：16位采樣@ 16000Hz，1個通道。很明顯，這種格式需要256Kbps的吞吐量，這比BLE（200Kbps）的典型應(yīng)用吞吐量高。這就是為了減少所需的吞吐量，將pcm樣本的ADPCM調(diào)制引入RC側(cè)的原因。

自適應(yīng)差分脈碼調(diào)制（Adaptive Differential Pulse Code Modulation，ADPCM）是一種廣泛應(yīng)用于整個電信行業(yè)的音頻編碼技術(shù)。它通過計(jì)算標(biāo)準(zhǔn)脈碼調(diào)制（PCM）中兩個連續(xù)樣本之間的差異并將“預(yù)測”下一個樣本增量（從前一個采樣增量）的誤差編碼為真實(shí)樣本增量來工作。它是一種有損壓縮技術(shù)，它可以實(shí)現(xiàn)4：1的壓縮比，同時返回高質(zhì)量的信號，具有快速調(diào)制/解調(diào)所需的很少的處理能力。ADPCM算法的內(nèi)部結(jié)構(gòu)不在本文的范圍之內(nèi)。如果有興趣，讀者可以在[3]中了解更多。

語音搜索守護(hù)進(jìn)程（BTVOICED）

守護(hù)程序從hidraw設(shè)備讀取音頻數(shù)據(jù)并將其寫入ALSA捕獲設(shè)備。詳細(xì)信息如下：

  1. 初始化時，它將通過上述/dev/snd_bt接口通過自定義ioctl調(diào)用創(chuàng)建一個音頻捕獲設(shè)備。初始化后，在系統(tǒng)中創(chuàng)建標(biāo)準(zhǔn)的ALSA音頻捕獲設(shè)備：/dev /snd/pcmC0D0c。

  2. 它從hidraw設(shè)備讀取數(shù)據(jù)。這個讀取是一個阻塞操作，只有當(dāng)有新數(shù)據(jù)可用時，read()調(diào)用才會返回。

我們有四種類型的數(shù)據(jù)包：

  1. RC鍵
  2. 啟動音頻控制包（在RC上按下麥克風(fēng)鍵時發(fā)送）
  3. 停止音頻控制包（當(dāng)RC上釋放麥克風(fēng)鍵時發(fā)送）
  4. 音頻數(shù)據(jù)包（語音有效載荷）

接收到的數(shù)據(jù)包的處理比較簡單。RC鍵只是被忽略，因?yàn)閮?nèi)核輸入事件框架將會處理它們。在啟動音頻控制包時，只需要重新初始化ADPCM解碼算法，以避免解碼的pcm流中的DC偏移偽像（artifacts）。語音有效載荷數(shù)據(jù)包被ADPCM解碼，緩沖用于最小化用戶空間 - 內(nèi)核空間寫入遍歷并寫入/dev/snd_bt。由于Android語音搜索應(yīng)用程序是決定何時停止捕獲的組件，基于靜默期檢測（silence period detection），我們需要覆蓋用戶太早釋放麥克風(fēng)鍵的情況，也就是在應(yīng)用程序檢測到靜音期之前。因此，停止音頻控制分組時，btvoiced繼續(xù)以靜音字節(jié)（silence bytes）饋送alsa捕獲設(shè)備，直到Android應(yīng)用程序決定停止捕獲。這通過將零寫入/dev/snd_bt來實(shí)現(xiàn)，直到write()調(diào)用開始失敗。

btvoiced守護(hù)進(jìn)程的作用可以歸納為：從hidraw設(shè)備中提取音頻數(shù)據(jù)，ADPCM解碼，將PCM寫入/dev/snd_bt以及停止音頻控制數(shù)據(jù)包的靜音填充。

捕獲設(shè)備Alsa驅(qū)動程序（snd_bt）

snd_bt是一個內(nèi)核模塊，提供：

  1. 一個簡單的可寫的char設(shè)備/dev/snd_bt作為btvoiced守護(hù)進(jìn)程寫入解碼的pcm樣本的接口。

  2. 標(biāo)準(zhǔn)接口，Android語音搜索框架讀取pcm采樣，以ALSA捕獲設(shè)備（/dev/sndipcmCxDxc）的形式，

創(chuàng)建一個可寫的char設(shè)備是簡單的注冊新的struct miscdevice以及所需的文件操作：open()，write()，ioctl()和close()。ioctl()操作用于創(chuàng)建ALSA設(shè)備，如下所述，write()操作是捕獲過程的主要部分。

為了創(chuàng)建捕獲設(shè)備接口，snd_bt驅(qū)動程序使用內(nèi)核ALSA結(jié)構(gòu)和API函數(shù)。

模塊中使用的核心內(nèi)核ALSA結(jié)構(gòu)如下：

  • struct snd_card

ALSA表示聲卡。

  • struct snd_pcm

可實(shí)現(xiàn)捕獲，播放或控制設(shè)備的PCM實(shí)例的ALSA表示。

代表btvoaved守護(hù)進(jìn)程的Idev / snd bt上的核心內(nèi)核ALSA API函數(shù)稱為ioctl（）：

  • snd_card_create()

創(chuàng)建和初始化聲卡結(jié)構(gòu)。

  • snd_pcm_new()

創(chuàng)建一個新的PCM實(shí)例，它是捕獲設(shè)備的ALSA表示形式。

  • snd_pcm_set_ops()

將PCM操作函數(shù)注冊到PCM實(shí)例。PCM操作函數(shù)prepare()，trigger()和pointer()是捕獲過程中由ALSA內(nèi)核調(diào)用的回調(diào)函數(shù)。

  • snd_card_register()

注冊分配給聲卡的所有設(shè)備。在我們的例子中，我們只有一個捕獲設(shè)備。在此調(diào)用完成后，ALSA捕獲設(shè)備已準(zhǔn)備好由Android語音捕獲框架使用。

聯(lián)合起來

總體RC數(shù)據(jù)包處理如下圖所示

圖5 RC數(shù)據(jù)包處理

在處理RC數(shù)據(jù)包時，可以區(qū)分兩種不同的STB操作模式。標(biāo)示為“HOGP設(shè)備按鍵事件處理”的第一種模式是圖3中更詳細(xì)說明的鍵事件的常規(guī)處理。圖4所示的第二種模式“語音流處理”是BLE實(shí)現(xiàn)中的實(shí)際語音。通過按下并釋放RC上的“魔術(shù)”麥克風(fēng)鍵，可以啟動這兩種模式之間的切換。

第六部分 驗(yàn)證

作為驗(yàn)證工具，我們采用了兩步法。首先我們驗(yàn)證了所捕獲的語音流的質(zhì)量。之后，我們驗(yàn)證了與語音搜索應(yīng)用程序的正確集成。

對于第一步，我們以PCM轉(zhuǎn)儲的形式錄制語音搜索模式，語音搜索框架從snd_bt Alsa設(shè)備讀?。ㄒ妶D4）。使用Audacity（開源音頻編輯器和錄像機(jī)），我們驗(yàn)證了沒有明顯的損壞，如DC偏移，PCM樣本丟失等。下圖是在Audacity中導(dǎo)入的口語搜索模式PCM轉(zhuǎn)儲的示例。

圖6 “打開Netflix”測試模式pcm轉(zhuǎn)儲導(dǎo)入audacity

作為第二步，我們通過BLE RC功能測試了Google語音搜索的整體用戶體驗(yàn)。一組20名測試對象通過以下方式傳達(dá)了一系列預(yù)定義的搜索模式（如可口可樂，梅賽德斯，著名電影演員等）

  • BLE遙控器
  • 標(biāo)準(zhǔn)USB麥克風(fēng)

并驗(yàn)證了搜索結(jié)果。在這兩種情況下，我們的識別率達(dá)到了80％。盡管有前途，這些結(jié)果是有爭議的，因?yàn)樗鼈兏叨纫蕾囉贕oogle的語音識別算法。對于更正式的驗(yàn)證措施，我們建議改進(jìn)步驟1的方法。如何正式證明BLE傳輸造成的語音流中沒有任何破損的問題仍然存在。

第七部分 結(jié)論

在本文中，我們提出了一個在Android平臺上使用BLE遙控器作為語音捕獲設(shè)備的解決方案。我們決定使用現(xiàn)有的HOGP配置文件，將語音流視為一系列常規(guī)的鍵事件，而不是為低帶寬語音開發(fā)自定義的GATT服務(wù)。提出的概念通過兩個軟件模塊實(shí)現(xiàn)：語音搜索守護(hù)程序（btvoiced）和ALSA捕獲設(shè)備驅(qū)動程序（snd_bt）。通過引入語音流的ADPCM調(diào)制來解決由BLE的低數(shù)據(jù)吞吐量施加的限制。然而，正式的測試和驗(yàn)證程序沒有定義，作為非正式措施，提出的解決方案的最終用戶體驗(yàn)是有前途的，達(dá)到80％的識別率。正式的驗(yàn)證工具和測試程序的定義是今后工作的主題。

致謝

這項(xiàng)工作得到塞爾維亞共和國教育，科學(xué)和技術(shù)發(fā)展部的部分支持，得到撥款：32014。

參考文獻(xiàn)

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容