本頁面由 Cloud Translation API 翻譯而成。

USB數字音頻

本文回顧了 Android 對 USB 數位音訊和相關 USB 協定的支援。

觀眾

本文的目標受眾是 Android 設備 OEM、SoC 供應商、USB 音訊週邊供應商、高級音訊應用程式開發人員以及其他尋求詳細了解 Android 上 USB 數位音訊內部結構的人員。

Nexus 裝置的最終使用者應參閱Nexus 說明中心的文章使用 USB 主機模式錄製和播放音訊。儘管本文不面向最終用戶，但某些發燒友消費者可能會發現感興趣的部分。

USB概述

通用序列匯流排 (USB) 在 Wikipedia 文章USB中進行了非正式描述，並由USB Implementers Forum, Inc發布的標準正式定義。為了方便起見，我們在此總結了 USB 的關鍵概念，但標準才是權威參考。

基本概念和術語

USB 是一種具有單一資料傳輸操作發起者（稱為主機）的匯流排。主機透過匯流排與外設通訊。

注意：術語“設備”和“配件”是“外圍設備”的常見同義詞。我們在這裡避免使用這些術語，因為它們可能會與 Android裝置或稱為附件模式的 Android 特定概念混淆。

一個關鍵的主機角色是枚舉：偵測哪些週邊連接到匯流排並查詢透過描述符表示的屬性的過程。

一個週邊可能是一個物理對象，但實際上實現了多種邏輯功能。例如，網路攝影機週邊設備可以同時具有攝影機功能和麥克風音訊功能。

每個外圍功能都有一個接口，定義與該功能通訊的協定。

主機透過管道與外設進行通信，該管道到達端點、由外設功能之一提供的資料來源或接收器。

有兩種管道：訊息和流。訊息管道用於雙向控制和狀態。流管道用於單向資料傳輸。

主機啟動所有資料傳輸，因此術語輸入和輸出是相對於主機來表達的。輸入操作將資料從外設傳輸到主機，而輸出操作將資料從主機傳輸到週邊。

共有三種主要的資料傳輸模式：中斷、批量和等時。等時模式將在音訊方面進一步討論。

週邊設備可以具有連接到外圍設備本身之外的外部世界的終端。透過這種方式，週邊設備可以在 USB 協定和「現實世界」訊號之間進行轉換。端子是功能的邏輯物件。

安卓 USB 模式

開發模式

開發模式自 Android 最初發布以來就已經存在。對於執行 Linux、Mac OS X 或 Windows 等桌面作業系統的主機 PC，Android 裝置表現為 USB 週邊裝置。唯一可見的周邊功能是Android fastboot或Android 調試橋 (adb) 。 fastboot 和 adb 協定是基於 USB 批次資料傳輸模式分層。

主機模式

主機模式是在 Android 3.1（API 等級 12）中引入的。

由於 Android 裝置必須充當主機，且大多數 Android 裝置都包含不直接允許主機操作的 micro-USB 連接器，因此通常需要這樣的便攜式 ( OTG ) 轉接器：

圖 1.便攜式 (OTG) 轉接器

Android 裝置可能無法提供足夠的電量來操作特定週邊裝置，這取決於週邊裝置需要多少電量以及 Android 裝置能夠提供多少電量。即使有足夠的電量，Android 裝置的電池充電時間也可能會大幅縮短。對於這些情況，請使用供電集線器，如下所示：

圖 2.供電集線器

配件方式

Accessory 模式在 Android 3.1（API 等級 12）中引入，並向後移植到 Android 2.3.4。在此模式下，Android 裝置作為 USB 週邊裝置運行，受另一個裝置（例如充當主機的擴充座）的控制。開發模式和附件模式之間的差異在於，除了 adb 之外，主機還可以看到額外的 USB 功能。 Android 裝置從開發模式開始，然後透過重新協商流程轉換為配件模式。

配件模式在 Android 4.1 中擴展了附加功能，特別是下面描述的音訊。

USB音訊

USB類

每個週邊功能都有一個關聯的設備類文檔，用於指定該功能的標準協定。這使得符合類別標準的主機和周邊功能能夠互通，而無需詳細了解彼此的工作原理。如果主機和周邊由不同的實體提供，則類別合規性至關重要。

術語「無驅動」是「類別相容」的常見同義詞，表示可以使用此類週邊設備的標準功能，而無需安裝作業系統特定的驅動程式。人們可以假設，對於主要桌面作業系統來說，標榜為「無需驅動程式」的周邊設備將符合類別標準，儘管可能存在例外。

USB音訊類

這裡我們只關心實現音訊功能的外設，因此遵循音訊設備類別。 USB 音訊類別規格有兩個版本：1 類別 (UAC1) 和 2 類別 (UAC2)。

與其他班級的比較

USB 包括許多其他裝置類別，其中一些可能會與音訊類別混淆。海量儲存類別(MSC) 用於面向磁區的媒體訪問，而媒體傳輸協定(MTP) 用於對媒體的完整檔案存取。 MSC 和 MTP 都可以用於傳輸音訊文件，但只有 USB 音訊類別適合即時串流媒體。

音訊終端

音頻外圍設備的端子通常是模擬的。週邊輸入端子處呈現的類比訊號由類比數位轉換器(ADC) 轉換為數位訊號，並透過 USB 協定傳送以供主機使用。 ADC 是主機的資料來源。同樣，主機透過 USB 協定將數位音訊訊號傳送到外設，其中數位類比轉換器(DAC) 進行轉換並呈現到類比輸出終端。 DAC 是主機的接收器。

頻道

具有音訊功能的周邊設備可以包括來源終端、接收終端或兩者。每個方向可以有一個通道（單聲道）、兩個通道（立體聲）或更多。具有兩個以上通道的周邊稱為多通道。通常將立體聲流解釋為由左聲道和右聲道組成，並且透過擴展將多聲道流解釋為具有與每個聲道相對應的空間位置。然而，不為每個通道分配任何特定的標準空間含義也是非常合適的（特別是對於 USB 音訊而言，比HDMI更是如此）。在這種情況下，由應用程式和使用者定義如何使用每個通道。例如，四通道 USB 輸入流的前三個通道可能連接到房間內的各個麥克風，最後一個通道接收來自 AM 收音機的輸入。

等時傳輸模式

USB音訊由於其實時特性而使用等時傳輸模式，但以錯誤恢復為代價。在等時模式下，頻寬得到保證，並且使用循環冗餘校驗（CRC）來檢測資料傳輸錯誤。但如果發生錯誤，則不會進行資料包確認或重新傳輸。

等時傳輸發生在每個幀起始 (SOF) 週期。 SOF 週期在全速時為 1 毫秒，在高速時為 125 微秒。每個全速幀最多承載 1023 位元組的有效負載，高速幀最多承載 1024 位元組。將這些放在一起，我們計算出最大傳輸速率為每秒 1,023,000 或 8,192,000 位元組。這設定了組合音訊取樣率、通道數和位元深度的理論上限。實際限制較低。

在等時模式中，有三種種子模式：

自適應
非同步
同步

在自適應子模式中，週邊接收器或來源適應主機可能變化的取樣率。

在非同步（也稱為隱式回饋）子模式中，接收器或來源決定取樣率，主機適應。非同步子模式的主要理論優勢是來源或宿 USB 時鐘在物理和電氣上更接近（實際上可能與驅動 DAC 或 ADC 的時鐘相同或源自）。這種接近意味著非同步子模式應該不易受到時脈抖動的影響。此外，DAC 或 ADC 使用的時鐘可以設計為比主機時鐘具有更高的精度和更低的漂移。

在同步子模式下，每個 SOF 週期傳送固定數量的位元組。音訊取樣率實際上源自 USB 時鐘。同步子模式不常用於音頻，因為主機和周邊都受 USB 時鐘的支配。

下表總結了等時子模式：

子模式	位元組數每包	取樣率取決於	用於音訊
適應性	多變的	主持人	是的
非同步	多變的	週邊	是的
同步	固定的	USB時鐘	不

在實踐中，子模式當然很重要，但也應該考慮其他因素。

Android 對 USB 音訊類別的支持

開發模式

開發模式不支援 USB 音訊。

主機模式

Android 5.0（API 等級 21）及更高版本支援 USB 音訊 1 類別 (UAC1) 功能的子集：

Android 裝置必須充當主機
音訊格式必須是 PCM（介面類型 I）
位元深度必須為 16 位元、24 位元或 32 位元，其中 24 位元有用音訊資料在 32 位元字的最高有效位元內左對齊
取樣率必須為 48、44.1、32、24、22.05、16、12、11.025 或 8 kHz
通道數必須為 1（單聲道）或 2（立體聲）

仔細閱讀 Android 框架原始碼可能會發現超出支援這些功能所需的最少程式碼的其他程式碼。但該程式碼尚未經過驗證，因此尚未聲明更高級的功能。

配件方式

Android 4.1（API 等級 16）為主機增加了對音訊播放的有限支援。在配件模式下，Android 會自動將其音訊輸出路由到 USB。也就是說，Android裝置充當主機的資料來源，例如dock。

配件模式音訊具有以下功能：

Android 裝置必須由知識豐富的主機控制，該主機可以先將 Android 裝置從開發模式轉換為附件模式，然後主機必須從適當的端點傳輸音訊資料。因此，Android 裝置對於主機來說並不顯得「無驅動」。
方向必須輸入，表示相對於主機
音訊格式必須是 16 位元 PCM
取樣率必須為 44.1 kHz
頻道數必須為 2（立體聲）

配件模式音訊尚未被廣泛採用，目前不建議用於新設計。

USB數位音訊的應用

顧名思義，USB數位音訊訊號由數位資料流表示，而不是常見的TRS迷你耳機連接器使用的類比訊號。最終，任何數位訊號都必須轉換為類比訊號才能被聽到。在選擇轉換的位置時需要權衡。

兩個 DAC 的故事

在下面的範例圖中，我們比較了兩種設計。首先，我們有一個行動設備，具有應用處理器 (AP)、板載 DAC、放大器和連接到耳機的類比 TRS 連接器。我們還考慮使用 USB 連接到外部 USB DAC 和放大器以及耳機的行動裝置。

圖 3.兩種 DAC 的比較

哪種設計比較好？答案取決於您的需求。每個都有優點和缺點。

注意：這是一個人為的比較，因為真正的 Android 裝置可能會同時提供這兩個選項。

第一種設計 A 更簡單、更便宜、使用更少的功率，並且假設其他方面同樣可靠的組件，將是更可靠的設計。然而，音訊品質與其他要求之間通常需要權衡。例如，如果這是一款大眾市場設備，它的設計可能是為了滿足一般消費者的需求，而不是為了發燒友的需求。

在第二種設計中，外部音訊週邊C可以設計為更高的音訊品質和更大的功率輸出，而不會影響基本大眾市場Android設備B的成本。是的，這是一個更昂貴的設計，但成本僅被吸收那些想要它的人。

行動裝置因採用高密度電路板而臭名昭著，這可能會導致更多的串擾機會，從而降低相鄰類比訊號的品質。數位通訊不易受雜訊影響，因此將 DAC 從 Android 裝置 A 移至外部電路板 C 可使最終類比等級與密集且雜訊的電路板在實體和電氣上隔離，從而獲得更高保真度的音訊。

另一方面，第二種設計更加複雜，隨著複雜性的增加，失敗的機會也隨之增加。 USB 控制器也會產生額外的延遲。

主機模式應用

典型的 USB 主機模式音訊應用包括：

聽音樂
電話
即時通訊和語音聊天
記錄

對於所有這些應用程序，Android 會偵測相容的 USB 數位音訊外設，並根據音訊策略規則自動路由音訊播放和擷取。立體聲內容在外圍設備的前兩個頻道上播放。

沒有特定於 USB 數位音訊的 API。對於進階使用，自動路由可能會幹擾 USB 感知的應用程式。對於此類應用程序，請透過「設定/開發人員選項」的「媒體」部分中的相應控制項停用自動路由。

在主機模式下調試

在 USB 主機模式下，無法透過 USB 進行 adb 偵錯。有關替代方案，請參閱Android 調試橋的無線使用部分。

實現USB音頻

對音頻週邊供應商的建議

為了與 Android 裝置進行互通，音訊外設供應商應該：

音頻類合規性設計；目前 Android 的目標是 1 類，但明智的做法是為 2 類做好規劃
避免怪癖
測試與參考和流行 Android 設備的互通性
清楚記錄支援的功能、音訊等級合規性、電源需求等，以便消費者做出明智的決定

對 Android 裝置 OEM 和 SoC 供應商的建議

為了支援 USB 數位音頻，設備 OEM 和 SoC 供應商應該：

設計硬體以支援USB主機模式
透過android.hardware.usb.host.xml功能標誌在框架層級啟用通用 USB 主機支持
啟用所需的所有核心功能：USB 主機模式、USB 音訊、同步傳輸模式；請參閱Android 內核配置
隨時了解最新的核心版本和補丁；儘管有類合規性的崇高目標，但現有的音訊週邊設備存在一些怪癖，並且最近的核心針對此類怪癖提供了解決方法
啟用 USB 音訊策略，如下所述
將audio.usb.default加入device.mk中的Product_PACKAGES中
測試與常見 USB 音訊週邊的互通性

啟用 USB 音訊策略

若要啟用 USB 音頻，請在音訊策略設定檔新增一個條目。它通常位於此處：

device/oem/codename/audio_policy.conf

路徑名部分「oem」應替換為製造 Android 裝置的 OEM 的名稱，「codename」應替換為裝置代碼名稱。

此處顯示了一個範例條目：

audio_hw_modules {
  ...
  usb {
    outputs {
      usb_accessory {
        sampling_rates 44100
        channel_masks AUDIO_CHANNEL_OUT_STEREO
        formats AUDIO_FORMAT_PCM_16_BIT
        devices AUDIO_DEVICE_OUT_USB_ACCESSORY
      }
      usb_device {
        sampling_rates dynamic
        channel_masks dynamic
        formats dynamic
        devices AUDIO_DEVICE_OUT_USB_DEVICE
      }
    }
    inputs {
      usb_device {
        sampling_rates dynamic
        channel_masks AUDIO_CHANNEL_IN_STEREO
        formats AUDIO_FORMAT_PCM_16_BIT
        devices AUDIO_DEVICE_IN_USB_DEVICE
      }
    }
  }
  ...
}

原始碼

USB 音訊的音訊硬體抽象層 (HAL) 實現位於此處：

hardware/libhardware/modules/usbaudio/

USB 音訊 HAL 嚴重依賴tinyalsa ，如音訊術語所述。儘管 USB 音訊依賴同步傳輸，但 ALSA 實作將其抽象化。所以USB音頻HAL和tinyalsa不需要關心USB協定的這一部分。

測試USB音頻

有關 USB 音訊 CTS 測試的信息，請參閱USB 音訊 CTS 驗證器測試。