雲控平臺的雙向音頻解決方案

導讀

隨着移動互聯網的發展，行業內衍生了基於移動平臺的各種解決方案。其中，設備規模化管理的雲控能力是各互聯網公司在設備集羣控制背景下的訴求。所以涌現了大批提供相似解決方案的平臺。如：阿里系的阿里雲MQC、阿里無線和菜鳥Nimitz等，阿里以外的有Testin、百度MTC、騰訊WeTest、華爲、三星等等。

目前以上平臺在雲真機的使用上，都存在一個已知的短板 —— 聲音。用戶看的到畫面，可以響應操做，可是涉及到聲音播報、語音交互的場景時則無能爲力。尤爲對於音樂、視聽、短視頻、直播客戶端等這類多媒體屬性強的App，在雲真機的使用場景上是受限最大的。

如今回到咱們本身的產品。高德地圖車機/鏡版（後面統稱Auto）。其中最多見的導航播報、與系統的多媒體混音交互、以及語音助手多輪對話的交互場景中，這些與聲音相關的場景佔比高達25%以上。因此解決遠程場景下的聲音雙向交互問題，是雲真機要成爲一個平常化的生產工具以前必須邁過的坎。

挑戰

在遠程音頻的雙向通信解決方案的背景下，知足基本用戶體驗的方面也存在如下挑戰：

• 能力：知足全部車載設備的聲音場景的雙向交互能力（由於車載設備在聲音部分比手機具備更高的定製性，在覆蓋車載場景後，手機基本能夠無縫適配）；
• 延遲：傳輸延遲低於500ms（基於必定的網絡條件）；
• 體驗：無明顯卡頓、雜音問題。

設想

首先經過下面的一張圖來了解一下咱們的需求是什麼：

• 將聲音經過電腦傳輸到遠端的車機設備（車機系統能正常解析處理）；
• 將車機經過喇叭播報出的聲音傳輸到用戶端。

而實現這兩條鏈路，關鍵核心的兩個因素是：

• 如何獲取和寫入音頻數據；
• 如何實現實時的音頻數據在車機和用戶設備間的傳輸鏈路。

音頻獲取和寫入

Android系統音頻概要

在思考如何進行設備的音頻獲取前，咱們先來了解下Android的音頻系統架構：

上圖描述了音頻通訊從應用層、Libraries、HAL、到Driver，最後到硬件模塊各層主要實現。而咱們也須要從這條鏈路中去挖掘獲取和寫入音頻數據的思路。

首先，咱們考慮的是Android對應的音頻鏈路中是否有成熟的支持雙向音頻的能力。即音頻數據在OS內部獲取到對外傳輸。

REMOTE_SUBMIX

API 19新加的MediaRecorder. AudioSource. REMOTE_ SUBMIX，用於傳輸系統混音的音頻流到遠端（在API 18也存在，只是屬於隱藏屬性）。

因爲要生效REMOTE_SUBMIX，須要Manifest. permission. CAPTURE_ AUDIO_ OUTPUT權限，而該權限只有系統組件才具有。也就是若是第三方App須要的話，須要進行系統簽名或者在燒寫OS版本時就修改對應的權限。做爲系統方是能夠這麼操做的，但顯然對於要適配全部系統方的咱們來講不適用。

軟件hook

考慮到咱們拿到的車載設備中，root比例高達80%以上。所以咱們想從在音頻數據傳輸到底層硬件驅動前進行「截胡」。也就是hook HAL定義的往驅動寫入和讀取對應音頻數據的方法，來達到音頻數據的雙向獲取。

• hook HAL hardware

hw hook的是struct audio_hw_device的
音頻輸出：open_output_stream、close_output_stream
音頻輸入：open_input_stream、close_input_stream

system/lib/hw/audio.primary.*.so (不一樣的設備有後綴部分差別)

• hook tinyalsa

在實際的調研測試中，咱們發現並非每臺設備都能經過hook hw 來獲取到對應的聲音數據，尤爲是車載設備。因而咱們又調研了ALSA（Advanced Linux Sound Architecture）高級Linux聲音架構。根據官方的推薦，咱們選擇了具有GPL-licensed 的external/tinyalsa

hook tinyalsa.so

音頻輸出：pcm_open、pcm_close、pcm_write、pcm_mmap_write

音頻輸入：pcm_open、pcm_close、pcm_read、pcm_mmap_read

system/lib/libtinyalsa.so

• 問題

在實際摸底驗證中，咱們發現車機比手機還複雜的緣由在於多了功放的概念，而部分車廠選擇在設備的DSP模塊去處理混音。帶來的問題就是部分設備若是單純的經過hook播報，對應聽到的聲音與設備真實經過喇叭播報的效果不一樣，這也致使咱們對於該場景的還原並不真實。

所以，在於root設備覆蓋不徹底且部分設備存在硬件功放處理混音問題的狀況下，軟件hook的方案只能適用於部分設備。

• 成本

hook自身也會帶來一個問題，即針對不一樣的車機須要每臺都進行hook處理，使得hook帶來的成本太高。須要批量一鍵hook來解決這個問題。

分析到這裏，咱們回顧下音頻傳輸的鏈路：

基於以上咱們對音頻獲取的這條傳輸鏈路上的分析，如今理論上可行的獲取途徑，就只有硬件的對接或者具體的接收端（喇叭、藍牙）。

usb音頻

硬件對接部分，在雲控場景下，咱們的設備一般是經過USB線束與咱們的節點PC鏈接的。所以音頻經過USB進行傳輸的鏈路，也是一個值得探索的方向。

咱們知道，Android設備在鏈接usb時有三種模式：Host、Development、Accessory Mode：

• 主機模式：能夠傳輸音頻，可是Android設備做爲主機，沒法使用adb的能力；
• 開發者模式：具有adb的能力，可是沒有現成的USB音頻能力；
• 配件模式：既保留了adb的能力，在Android4.1後的配件模式下，Android 也能自動將其音頻輸出導向到USB。

思路：經過實現AOA協議，做爲主機角色的設備，必須具備可以將Android設備從開發模式切換到配件模式的主機控制能力，而後主機從適當的端點傳輸音頻數據

該方案的侷限性在於：一、單向傳輸；二、配件模式取決於設備硬件，但並不是全部設備都支持。實測過程當中，車機支持配件模式的比例很低，絕大多數都被「閹割」了。

綜上，咱們沒法靠單純的某種USB模式來實現音頻的雙向交互。但若是是手機集羣的場景中，這個方案卻是能夠做爲單向音頻傳輸的一個優選方案。

藍牙接收

聲音除了能夠經過usb傳輸之外，常見的方式還有藍牙耳機、有線耳機。（這裏因爲車載設備不存在3.5mm孔，因此咱們先不討論有線方式，具體可參考後面「硬件轉發」的方案）。

關於藍牙接收的基本思路就是PC端經過安裝藍牙接收器與車機通訊。其中藍牙接收器起到相似於藍牙耳機的做用。而後對藍牙接收器的收發數據在PC端進行編碼處理。

藍牙耳機：具有了能夠據說的能力，也就是雙向的音頻通訊。

摸底驗證：部分車機對藍牙驅動進行了定製，使得藍牙設備只能做爲從設備，沒法接入藍牙耳機功能。咱們測試了35臺，其中5臺能夠用，成功率14%，收益過低，成本太高。這個方案若是是面向手機集羣，卻是一個不錯的選擇，理論上成功率應該會大大高於車載設備。

硬件轉發

上面提到的有線耳機的思路。在車載設備上，不存在3.5mm孔或者type C口，而是經過主機與功放、音箱外放裝置進行鏈接。在車輛量產上市前的研發階段，只是一個主機經過線束鏈接着喇叭的一個過渡狀態。因此咱們實際是經過將本來接到喇叭上的音頻數據經過一種轉換裝置轉接到PC上，在PC端進行音頻編碼處理。

大體的參考示意效果以下：

上述方案的優點在於：

• 跨平臺，不論是Android、Linux、QNX或者iOS的設備都適用；
• 解決了混音問題，因爲對接的是最終播報出的聲音效果，就不存在軟件hook可能還原不真實的問題；
• 支持雙向音頻通訊。

缺點：

• 部分智能車鏡設備，因爲集成封裝性太強，沒有暴露出可對接的線束。這類設備不容易經過該方案覆蓋；
• 須要針對車機進行線束定製來實現總體的動態封裝性；
• 須要配套的硬件成本。

硬件轉發方案中存在幾個方面的問題須要注意，好比失真問題、聲卡識別問題、usb兼容上限、聲卡與ehci、xhci的兼容性問題以及總體封裝設計等等。

小結

綜合以上音頻傳輸的整條鏈路的全部方案，咱們列舉對比下這些方案的優劣（特指在車載場景下）：

基於上述狀況，考慮到車載的應用場景。最終咱們的選型是 「軟件hook」 +「硬件轉發」的組合方案。

音頻編碼傳輸

關於音頻編碼傳輸這部分的內容，行業中已經有較成熟的解決方案，所以，這部分不展開篇幅討論，咱們僅針對一些方案作選型評估：

綜上，從咱們的應用場景以及高實時性要求考慮，最終選取了webRtc的方案。

最終選型

結合音頻的獲取和寫入以及總體編碼傳輸的方案，最終的技術方案選型圖以下：

對應流程圖中，也順帶涵蓋了遠程畫面傳輸的視頻流優化的參考鏈路。

總結

經過軟硬件組合的方案來實現音頻數據讀寫的能力，是一種基於特定背景條件下解決方案。但其基本推演的思路和策略，也是適用於手機平臺的。而其中硬件的解決方案，理論上是適用於Android、iOS、Linux、QNX等平臺設備的。

相較來講，手機的硬件轉發成本更低。而對於軟件的方案，實際的播報效果上仍會有不少細節問題，好比播報聲音過小，須要對應設備去調節播報音量比例；出現延遲的場景，可能須要修改採樣率；或是須要hook的自動化來下降成本等等。最終落地到項目中時，還須要考慮各方面的適配成本，確保總體的投入產出比。

關注高德技術，找到更多出行技術領域專業內容