導讀

隨著移動互聯網的發展，行業內衍生了基於移動平臺的各類解決方案。其中，設備規模化管理的雲控能力是各互聯網公司在設備集群控制背景下的訴求。因此湧現了大批提供類似解決方案的平臺。如：阿里系的阿里雲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設備從開發模式切換到配件模式的主機控制能力，然後主機從適當的端點傳輸音頻數據

該方案的侷限性在於：1、單向傳輸；2、配件模式取決於設備硬件，但並非所有設備都支持。實測過程中，車機支持配件模式的比例很低，絕大多數都被“閹割”了。

綜上，我們無法靠單純的某種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的自動化來降低成本等等。最終落地到項目中時，還需要考慮各方面的適配成本，確保整體的投入產出比。