時下智能語音交互市場火熱，越來越多的設備都開始支持遠場AI語音交互。
例如：智能音箱，智能電視等等。但這類產品的識別率和誤喚醒率還需再不斷的優化提升，以至於日常生活中人們還是離不開各式各樣的遙控器。而藍牙語音遙控器這一產品，作為遠場語音交互的一個近場配件，也搭上了這趟語音交互的快速列車，成長速度令人驚訝。基於Actions炬芯的ATB1103晶片的語音遙控器，打造了一個AIoT時代的高性價比精品。
一、遙控器應用總體架構
遙控器總體架構分四層，從上到下依次為應用層、應用框架層、硬體抽象層、底層驅動層
1.1、應用層
• 應用狀態機– 事件觸發讓遙控器應用處理不同的狀態
• 應用定時器– 定時觸發不同的事件，驅動遙控器正常運行
• 應用輸入處理– 處理底層來的不同按鍵消息
• 應用音頻輸入處理– 將底層的音頻處理消息，進行編碼，然後通過藍牙發送給對端設備
• BLE profile
– HID profile，提供按鍵輸入輸出接口服務
– BAS service，提供電池服務
– DIS service，提供讀取設備基本信息的接口服務
– ota profile，提供OTA 升級服務
1.2、應用框架層
• 輸入管理– 按鍵映射處理、按鍵過濾機制
• 消息管理– 消息分配和釋放、 消息發送和接收
• 內存管理– 動態內存管理
• 閃燈管理– 燈資源分配和釋放
• 電池管理– 電量讀取、電量管理策略
1.3、硬體抽象層
將應用層和驅動層剝離開的中間件層
1.4、底層驅動層
底層硬體操作接口
二、遙控器模塊流程概述
2.1、系統啟動
系統相關初始化、板級相關外設初始化、藍牙協議棧相關初始化、HidApp 應用初始化，並進入Main 主循環，等待消息處理
2.2、遙控器狀態機
遙控器在運行過程中，主要靠如下3 種狀態維持他的正常運行。
2.2.1. 觸發遙控器進去空閒狀態的事件：
> 廣播狀態，沒有連接成功，出現超時事件，進入idle
> 連接狀態，斷開連接，如無操作主動斷開連接，然後進入idle
2.2.2. 觸發遙控器進入激活狀態的事件：
> 空閒狀態，有按鍵、首次上電，進入激活狀態
> 連接狀態，出現異常斷開，需要回連，進入激活狀態
2.2.3. 觸發遙控器進入工作狀態的事件：
> 激活狀態下，配對成功或者回連成功，進入工作狀態。
2.3、按鍵處理
由於遙控器的鍵值較多，通常用矩陣鍵盤方式以節省pin 的使用。當使能Key 模塊後，Key 控制器就會處於矩陣掃描狀態，當檢測到外部按鍵有值時，就會產生中斷，中斷就將按鍵信息上報給應用。
2.4、紅外處理
• 在非連接狀態下，按下按鍵，就會發射紅外碼，進而通過紅外操作對端設備，如使用紅外進行配對.
• IRC 協議上，最短的紅外碼重發時間為108 ms，而按鍵的重複上報時間，可能小於108ms，也可能大於108ms，因此按鍵輸入和紅外發送模塊時間上存在三種可能:
2.4.1. 慢速點按
慢速點按動作特徵是在大於Trpc 時間後有多次的按鍵輸入。在Ta 時刻，發出初次按鍵值，在Tb 時刻，不做任何響應，在Tc 時刻，繼續發送檢測到的按鍵值，不會發送重複碼.
2.4.2. 快速點按
快速點按的動作特徵是用戶在Trpc 時間內有兩次或者以上的按鍵按下彈起的動作. 在Ta 時刻，將發送出初次按鍵，而Tb 時刻並不發送按鍵值，在Tc 時刻，如果按鍵仍然是按下狀態，將發出按鍵值，否則將丟掉按鍵值.
2.4.3. 長按
長按的動作特徵是按鍵按下後，一直不放開。此時CPU 檢測到按鍵的持續按下，則在Ta 時刻發送出初次按鍵，發送出此時按鍵對應的紅外鍵碼，而在Trpc 時間內沒有檢測到按鍵的鬆開，則在Tb 時間輸出重複碼，直至檢測到按鍵彈起為止.
2.5、語音採集
• 當啟動Voice Key 後，ADC 開始採集
• 採集的數據通過DMA 搬運到應用的循環buffer 中，同時發送消息給Main 線程，讓其處理語音數據。
• 如果Main 線程處理速度不夠快，audioin 驅動就會因為分不到buffer，而將採集的語音數據丟棄。
2.6、BLE數據傳送
• 將audioin 驅動發送上來的數據進行編碼壓縮。
• 然後將編碼後的壓縮數據切成幾個20byte 的數據包
• 最後通過hid profile notify 接口發送給BLE 協議棧
2.7、應用軟體Timer管理模塊
2.8、LED管理模塊
遙控器定義了幾種LED 指示燈，用於指示遙控器的一些狀態，如下表所示
通常遙控器只有一個物理的LED 燈用於各種場景的指示，這就需要軟體上讓其分時復用，如果同時需要顯示兩種狀態，狀態需要定義優先級，優先級高的狀態先指示。如在配對模式下，處於閃燈狀態下，這時候按下按鍵，那麼燈還是處於快閃狀態。
2.9、OTA升級模塊
當前OTA 設計在應用中，系統隨時可以升級，升級過程中，系統的其他模塊仍然可以正常使用，升級完後，由對端設備決定是否重啟系統，如果對端設備沒有重啟系統，系統將在下一次上電的時候，使用新的固件。
2.10、電池管理模塊
電量檢測採用標準的BAS Service，實現電量的讀取（Read）和上報（Notification）。目前定義的電池電壓檢測範圍1.8 ～ 3.25V，線性等分對應0%-100%，由於沒有關機操作，當前配置了一個超低電門檻1.8V，低於超低門檻後，系統不再允許Nor 操作，藍牙連接也會自動斷開。BAS 的notification configuration characteristic 使能後，定時器每N 分鐘讀取一次電量並通過Notification 上報。
三、語音傳送的HID PROFILE 介紹
• GATT 服務需求
• Report Map 介紹
Report Map 屬性主要用於定義在HID Service 和report Host 端傳送的input report、output report、feature report 格式。每個HID service 只能包含一個report map 屬性，屬性值長度為小於等於512byte。
• HID Reports 介紹
當前定義3 種HID input report IDs:
– Remote report
用於傳送遙控器按鍵信息
– Voice report
用於傳送語音信息，每次report 的數據為20byte
– Mouse report
用於傳送空鼠信息，暫未使用
• Hid Profile 語音傳輸基本過程
– Client 端進行BLE 連接、配對及服務發現，並使能所有input 屬性通知屬性。
– Server 端通過HID profile 的Remote report 發送一個開始按鍵到Client 端，Client 準備接收audio Data。
– Server 端通過HID profile 的Audio Out 屬性發送voice Data 到Client 端。
– Server 端通過HID profile 的Remote report 發送一個結束按鍵，Client 停止接收audio Data.
四、按鍵編碼設計
五、按鍵行為規範
5.1 普通按鍵的行為
5.1.1. 在非連接狀態，喚醒系統，發送回連包或者配對廣播包，並通過紅外發送紅外碼
5.1.2. 在連接狀態下，發送藍牙碼
發送給遠端設備的按鍵行為大致為：
down–>down–>down->…–>up
設備端並不處理長按或者短按邏輯，交由遠端設備處理。
5.2 語音按鍵的行為
5.2.1. 在非連接狀態，喚醒系統，發送回連包或者配對廣播包
5.2.2. 在連接狀態下，Down 狀態發送語音開始標識，up 狀態發送語音結束標識。
發給遠端設備的按鍵行為大致為：
Down—>up
設備端過濾掉中間的down。
5.3 配對組合鍵的行為
配對組合按鍵會強制進入配對模式，發送配對廣播包觸發配對流程。
持續按住配對組合按鍵N s 以上，進入配對模式，之後的流程如下：
5.3.1. 如果有link key，先刪除link key
5.3.2. 如果是連接狀態，斷開連接, 如果是非連接狀態，發送配對廣播包
5.3.3. 組合鍵鍵值不會發送給遠端設備
六、休眠與喚醒
6.1 休眠
6.1.1. 在廣播狀態下，Host CPU 會進入deepsleep 狀態，BLE 控制器處於廣播狀態.
6.1.2. 在連接狀態下，不發送按鍵/語音，Host CPU 進入deepsleep，BLE 控制器處於連接狀態，如果connSlaveLatency = 44，連接間隔為10ms，那麼BLE 控制器進入deepsleep，每隔450 ms 醒來一次發一次空包回應對端，然後進入deepsleep 狀態.
6.1.3. 在連接狀態下，發送按鍵，按鍵發送完，進入2 狀態.
6.1.4. 在連接狀態下，發送語音，Host CPU 不會進入deepsleep，BLE 控制器處於連接狀態.
6.1.5. 在無連接和廣播狀態，Host CPU 和BLE 控制器都會進去deepsleep 狀態，即最省電模式，所以應用層還設計了在N 分鐘內沒有按鍵和語音操作，遙控器會主動斷開連接進入deepsleep 模式，達到最省電模式。
6.2 喚醒
6.2.1. 遙控器Host CPU 可以由藍牙事件喚醒，也可以由按鍵事件喚醒，還可以由timer事件喚醒
6.2.2. 在連接狀態下，按鍵操作喚醒Host CPU 然後將鍵碼/語音發出
6.2.3. 在沒有連接狀態下，按鍵操作會觸發進入回連模式，在回連成功後，將鍵碼發出
七、語音框架
總體框架如下圖所示，大致包括2 個過程：
• BLE Server 語音採集、編碼及傳輸
• BLE Client 語音接收、解碼及識別
7.1 BLE Server 語音採集、編碼及傳輸
7.1.1 MIC 語音採集
音頻驅動使用DMA 方式接收，配置一個N×SIZE 的BufferQueue，N 個buffer 循環配置給DMA 使用。當BufferQueue buffer 消耗完，最後一個buffer 被覆蓋使用。
7.1.2 語音編碼
• 語音編碼通常採用經典的IMA adpcm 編碼，壓縮率為1/4.
– 該算法優點：消耗CPU 和RAM 相對比較少
– 該算法缺點：壓縮率低，有損壓縮，音質一般
• 當前也設計支持了高壓縮高音質的1/8、1/16 音頻編碼算法
7.1.3 BLE 語音傳送
BLE 通過HID profile，按照每包20 個byte 數據將編碼後的數據傳送給對端BLE Hid Profile。
7.2 BLE Client 端語音接收、解碼及識別
7.2.1 BLE 語音接收
Android hid input 驅動收到BLE 數據，通過event 事件上報給input 子系統，input 子系統再將事件上報給適配的事件處理handler。
7.2.2 Audio 驅動解碼
當BLE hid 驅動收到遙控器開始語音按鍵後，就會開啟Audio 設備（虛擬mic 驅動），Audio 會開啟一個緩衝buffer 用於接收BLE 語音數據，當buffer 快滿的時候，Audio驅動啟動一個N ms 的timer 從buffer 取M byte 進行解碼，解碼後得到K byte 數據，然後放到pcm buffer 中。
7.2.3 錄音識別
如果Android 上層已經開啟錄音設備，錄音APK 就能從audioTrack 讀取audio HAL層語音數據，進而讀取Audio 設備驅動的pcm buffer 音頻數據，錄音APK 得到錄音數據，通過http 傳送遠程識別服務器，最終得到識別結果返回給本地。
例如：智能音箱，智能電視等等。但這類產品的識別率和誤喚醒率還需再不斷的優化提升，以至於日常生活中人們還是離不開各式各樣的遙控器。而藍牙語音遙控器這一產品，作為遠場語音交互的一個近場配件，也搭上了這趟語音交互的快速列車，成長速度令人驚訝。基於Actions炬芯的ATB1103晶片的語音遙控器，打造了一個AIoT時代的高性價比精品。
一、遙控器應用總體架構
遙控器總體架構分四層，從上到下依次為應用層、應用框架層、硬體抽象層、底層驅動層
1.1、應用層
• 應用狀態機– 事件觸發讓遙控器應用處理不同的狀態
• 應用定時器– 定時觸發不同的事件，驅動遙控器正常運行
• 應用輸入處理– 處理底層來的不同按鍵消息
• 應用音頻輸入處理– 將底層的音頻處理消息，進行編碼，然後通過藍牙發送給對端設備
• BLE profile
– HID profile，提供按鍵輸入輸出接口服務
– BAS service，提供電池服務
– DIS service，提供讀取設備基本信息的接口服務
– ota profile，提供OTA 升級服務
1.2、應用框架層
• 輸入管理– 按鍵映射處理、按鍵過濾機制
• 消息管理– 消息分配和釋放、 消息發送和接收
• 內存管理– 動態內存管理
• 閃燈管理– 燈資源分配和釋放
• 電池管理– 電量讀取、電量管理策略
1.3、硬體抽象層
將應用層和驅動層剝離開的中間件層
1.4、底層驅動層
底層硬體操作接口
二、遙控器模塊流程概述
2.1、系統啟動
系統相關初始化、板級相關外設初始化、藍牙協議棧相關初始化、HidApp 應用初始化，並進入Main 主循環，等待消息處理
2.2、遙控器狀態機
遙控器在運行過程中，主要靠如下3 種狀態維持他的正常運行。
2.2.1. 觸發遙控器進去空閒狀態的事件：
> 廣播狀態，沒有連接成功，出現超時事件，進入idle
> 連接狀態，斷開連接，如無操作主動斷開連接，然後進入idle
2.2.2. 觸發遙控器進入激活狀態的事件：
> 空閒狀態，有按鍵、首次上電，進入激活狀態
> 連接狀態，出現異常斷開，需要回連，進入激活狀態
2.2.3. 觸發遙控器進入工作狀態的事件：
> 激活狀態下，配對成功或者回連成功，進入工作狀態。
2.3、按鍵處理
由於遙控器的鍵值較多，通常用矩陣鍵盤方式以節省pin 的使用。當使能Key 模塊後，Key 控制器就會處於矩陣掃描狀態，當檢測到外部按鍵有值時，就會產生中斷，中斷就將按鍵信息上報給應用。
2.4、紅外處理
• 在非連接狀態下，按下按鍵，就會發射紅外碼，進而通過紅外操作對端設備，如使用紅外進行配對.
• IRC 協議上，最短的紅外碼重發時間為108 ms，而按鍵的重複上報時間，可能小於108ms，也可能大於108ms，因此按鍵輸入和紅外發送模塊時間上存在三種可能:
2.4.1. 慢速點按
慢速點按動作特徵是在大於Trpc 時間後有多次的按鍵輸入。在Ta 時刻，發出初次按鍵值，在Tb 時刻，不做任何響應，在Tc 時刻，繼續發送檢測到的按鍵值，不會發送重複碼.
2.4.2. 快速點按
快速點按的動作特徵是用戶在Trpc 時間內有兩次或者以上的按鍵按下彈起的動作. 在Ta 時刻，將發送出初次按鍵，而Tb 時刻並不發送按鍵值，在Tc 時刻，如果按鍵仍然是按下狀態，將發出按鍵值，否則將丟掉按鍵值.
2.4.3. 長按
長按的動作特徵是按鍵按下後，一直不放開。此時CPU 檢測到按鍵的持續按下，則在Ta 時刻發送出初次按鍵，發送出此時按鍵對應的紅外鍵碼，而在Trpc 時間內沒有檢測到按鍵的鬆開，則在Tb 時間輸出重複碼，直至檢測到按鍵彈起為止.
2.5、語音採集
• 當啟動Voice Key 後，ADC 開始採集
• 採集的數據通過DMA 搬運到應用的循環buffer 中，同時發送消息給Main 線程，讓其處理語音數據。
• 如果Main 線程處理速度不夠快，audioin 驅動就會因為分不到buffer，而將採集的語音數據丟棄。
2.6、BLE數據傳送
• 將audioin 驅動發送上來的數據進行編碼壓縮。
• 然後將編碼後的壓縮數據切成幾個20byte 的數據包
• 最後通過hid profile notify 接口發送給BLE 協議棧
2.7、應用軟體Timer管理模塊
2.8、LED管理模塊
遙控器定義了幾種LED 指示燈，用於指示遙控器的一些狀態，如下表所示
通常遙控器只有一個物理的LED 燈用於各種場景的指示，這就需要軟體上讓其分時復用，如果同時需要顯示兩種狀態，狀態需要定義優先級，優先級高的狀態先指示。如在配對模式下，處於閃燈狀態下，這時候按下按鍵，那麼燈還是處於快閃狀態。
2.9、OTA升級模塊
當前OTA 設計在應用中，系統隨時可以升級，升級過程中，系統的其他模塊仍然可以正常使用，升級完後，由對端設備決定是否重啟系統，如果對端設備沒有重啟系統，系統將在下一次上電的時候，使用新的固件。
2.10、電池管理模塊
電量檢測採用標準的BAS Service，實現電量的讀取（Read）和上報（Notification）。目前定義的電池電壓檢測範圍1.8 ～ 3.25V，線性等分對應0%-100%，由於沒有關機操作，當前配置了一個超低電門檻1.8V，低於超低門檻後，系統不再允許Nor 操作，藍牙連接也會自動斷開。BAS 的notification configuration characteristic 使能後，定時器每N 分鐘讀取一次電量並通過Notification 上報。
三、語音傳送的HID PROFILE 介紹
• GATT 服務需求
• Report Map 介紹
Report Map 屬性主要用於定義在HID Service 和report Host 端傳送的input report、output report、feature report 格式。每個HID service 只能包含一個report map 屬性，屬性值長度為小於等於512byte。
• HID Reports 介紹
當前定義3 種HID input report IDs:
– Remote report
用於傳送遙控器按鍵信息
– Voice report
用於傳送語音信息，每次report 的數據為20byte
– Mouse report
用於傳送空鼠信息，暫未使用
• Hid Profile 語音傳輸基本過程
– Client 端進行BLE 連接、配對及服務發現，並使能所有input 屬性通知屬性。
– Server 端通過HID profile 的Remote report 發送一個開始按鍵到Client 端，Client 準備接收audio Data。
– Server 端通過HID profile 的Audio Out 屬性發送voice Data 到Client 端。
– Server 端通過HID profile 的Remote report 發送一個結束按鍵，Client 停止接收audio Data.
四、按鍵編碼設計
五、按鍵行為規範
5.1 普通按鍵的行為
5.1.1. 在非連接狀態，喚醒系統，發送回連包或者配對廣播包，並通過紅外發送紅外碼
5.1.2. 在連接狀態下，發送藍牙碼
發送給遠端設備的按鍵行為大致為：
down–>down–>down->…–>up
設備端並不處理長按或者短按邏輯，交由遠端設備處理。
5.2 語音按鍵的行為
5.2.1. 在非連接狀態，喚醒系統，發送回連包或者配對廣播包
5.2.2. 在連接狀態下，Down 狀態發送語音開始標識，up 狀態發送語音結束標識。
發給遠端設備的按鍵行為大致為：
Down—>up
設備端過濾掉中間的down。
5.3 配對組合鍵的行為
配對組合按鍵會強制進入配對模式，發送配對廣播包觸發配對流程。
持續按住配對組合按鍵N s 以上，進入配對模式，之後的流程如下：
5.3.1. 如果有link key，先刪除link key
5.3.2. 如果是連接狀態，斷開連接, 如果是非連接狀態，發送配對廣播包
5.3.3. 組合鍵鍵值不會發送給遠端設備
六、休眠與喚醒
6.1 休眠
6.1.1. 在廣播狀態下，Host CPU 會進入deepsleep 狀態，BLE 控制器處於廣播狀態.
6.1.2. 在連接狀態下，不發送按鍵/語音，Host CPU 進入deepsleep，BLE 控制器處於連接狀態，如果connSlaveLatency = 44，連接間隔為10ms，那麼BLE 控制器進入deepsleep，每隔450 ms 醒來一次發一次空包回應對端，然後進入deepsleep 狀態.
6.1.3. 在連接狀態下，發送按鍵，按鍵發送完，進入2 狀態.
6.1.4. 在連接狀態下，發送語音，Host CPU 不會進入deepsleep，BLE 控制器處於連接狀態.
6.1.5. 在無連接和廣播狀態，Host CPU 和BLE 控制器都會進去deepsleep 狀態，即最省電模式，所以應用層還設計了在N 分鐘內沒有按鍵和語音操作，遙控器會主動斷開連接進入deepsleep 模式，達到最省電模式。
6.2 喚醒
6.2.1. 遙控器Host CPU 可以由藍牙事件喚醒，也可以由按鍵事件喚醒，還可以由timer事件喚醒
6.2.2. 在連接狀態下，按鍵操作喚醒Host CPU 然後將鍵碼/語音發出
6.2.3. 在沒有連接狀態下，按鍵操作會觸發進入回連模式，在回連成功後，將鍵碼發出
七、語音框架
總體框架如下圖所示，大致包括2 個過程：
• BLE Server 語音採集、編碼及傳輸
• BLE Client 語音接收、解碼及識別
7.1 BLE Server 語音採集、編碼及傳輸
7.1.1 MIC 語音採集
音頻驅動使用DMA 方式接收，配置一個N×SIZE 的BufferQueue，N 個buffer 循環配置給DMA 使用。當BufferQueue buffer 消耗完，最後一個buffer 被覆蓋使用。
7.1.2 語音編碼
• 語音編碼通常採用經典的IMA adpcm 編碼，壓縮率為1/4.
– 該算法優點：消耗CPU 和RAM 相對比較少
– 該算法缺點：壓縮率低，有損壓縮，音質一般
• 當前也設計支持了高壓縮高音質的1/8、1/16 音頻編碼算法
7.1.3 BLE 語音傳送
BLE 通過HID profile，按照每包20 個byte 數據將編碼後的數據傳送給對端BLE Hid Profile。
7.2 BLE Client 端語音接收、解碼及識別
7.2.1 BLE 語音接收
Android hid input 驅動收到BLE 數據，通過event 事件上報給input 子系統，input 子系統再將事件上報給適配的事件處理handler。
7.2.2 Audio 驅動解碼
當BLE hid 驅動收到遙控器開始語音按鍵後，就會開啟Audio 設備（虛擬mic 驅動），Audio 會開啟一個緩衝buffer 用於接收BLE 語音數據，當buffer 快滿的時候，Audio驅動啟動一個N ms 的timer 從buffer 取M byte 進行解碼，解碼後得到K byte 數據，然後放到pcm buffer 中。
7.2.3 錄音識別
如果Android 上層已經開啟錄音設備，錄音APK 就能從audioTrack 讀取audio HAL層語音數據，進而讀取Audio 設備驅動的pcm buffer 音頻數據，錄音APK 得到錄音數據，通過http 傳送遠程識別服務器，最終得到識別結果返回給本地。
►場景應用圖
►產品實體圖
►展示板照片
►方案方塊圖
►Actions語音遙控器方案Demo
►語音打開盒子端音樂
►語音切換盒子端電視頻道
►核心技術優勢
此方案目前已經在市面上量產，針對BLE Server端語音採集、編碼及傳輸到BLE Client端語音接收、解碼及識別有著完整完善的解決方法。 1、支持雙向語音傳輸（IIS OUT接口） 2、低功耗的voice adc，藍牙語音傳輸整機功耗 < 6mA 3、IMA ADPCM以及更高壓縮比的（16:1）語音編碼 4、支持紅外自學習（外圍電路省） 5、多按鍵、7pin支持35個按鍵（QFN32） 6、支持Find me/VAD
►方案規格
1、按鍵輸入：< 35 鍵 2、語音輸入：8k/16bit、16/16bit 3、 語音編碼：1/4 、1/8 、1/16 壓縮算法 4、紅外鍵碼輸出 5、BLE 鍵碼輸出、BLE 語音輸出 6、藍牙斷線後回連，並發送回連前的鍵值 7、電量檢測及電量管理