導讀

隨著移動網際網路的發展，行業內衍生了基於移動平臺的各類解決方案。其中，裝置規模化管理的雲控能力是各網際網路公司在裝置叢集控制背景下的訴求。因此湧現了大批提供類似解決方案的平臺。如：阿里系的阿里雲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的自動化來降低成本等等。最終落地到專案中時，還需要考慮各方面的適配成本，確保整體的投入產出比。

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