本頁面由 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 通訊協定和「實際」信號之間進行轉譯。終端是函式的邏輯物件。

Android USB 模式

開發模式

自 Android 初始版本推出以來，開發模式就一直存在。Android 裝置會顯示為 USB 外接裝置，連接至執行桌面作業系統 (例如 Linux、Mac OS X 或 Windows) 的主機電腦。唯一可見的周邊函式是 Android fastboot 或 Android Debug Bridge (ADB)。fastboot 和 ADB 通訊協定會在 USB 大量資料傳輸模式中層疊。

主機模式

主機模式是在 Android 3.1 (API 級別 12) 中導入。

由於 Android 裝置必須充當主機，而大多數 Android 裝置都內含 micro-USB 連接器，且無法直接允許主機運作，因此通常需要使用隨身裝置 (OTG) 轉接器，例如：

圖 1. On-the-go (OTG) 轉接器

視周邊裝置所需的電量和 Android 裝置可提供的電量而定，Android 裝置可能無法提供足夠的電力來運作特定周邊裝置。即使電量充足，Android 裝置的電池充電時間可能會大幅縮短。在這種情況下，請使用有電源的中樞，例如：

圖 2. 有線中樞

配件模式

配件模式是在 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 音訊會使用 isochronous 傳輸模式，以便提供即時特性，但代價是犧牲錯誤復原功能。在等時模式中，系統會保證頻寬，並使用循環冗餘檢查 (CRC) 偵測資料傳輸錯誤。但在發生錯誤時，系統不會提供封包確認或重新傳送。

每個影格起始 (SOF) 期間都會發生等時傳輸。全速的 SOF 週期為 1 毫秒，高速的 SOF 週期為 125 微秒。每個全速率影格最多可攜帶 1023 個位元組的酬載，而高速影格最多可攜帶 1024 個位元組。將這些值加總後，我們計算出的最高傳輸速率為每秒 1,023,000 或 8,192,000 個位元組。這會為組合音訊的取樣率、通道數和位元深度設定理論上限。實際限制較低。

在 isochronous 模式中，有三個子模式：

自動調整
非同步
同步

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

在非同步 (也稱為隱含回饋) 子模式中，接收端或來源會決定取樣率，主機則會配合。異步子模式的主要理論優點是，來源或接收端 USB 時脈在物理和電氣上更接近驅動 DAC 或 ADC 的時脈 (實際上可能與時脈相同，或衍生自時脈)。這種相近性表示非同步子模式不易受到時鐘抖動影響。此外，DAC 或 ADC 使用的時脈可能會比主機時脈更精確，且漂移幅度更低。

在同步子模式中，每個 SOF 週期會傳輸固定位元組數。音訊取樣率實際上是從 USB 時脈衍生而來。主機和外接裝置都受 USB 時脈控制，因此同步子模式通常不會用於音訊。

下表總結了 isochronous 子模式：

子模式	每個封包的位元組數	取樣率由	用於音訊
自動調節	機動	主人	是
非同步	機動	周邊裝置	是
同步	已修正	USB 時鐘	no

在實際操作中，子模式當然很重要，但也應考量其他因素。

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 裝置可做為主機 (例如基座) 的資料來源。

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

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 Debug Bridge 的「無線使用」一節。

實作 USB 音訊

給音訊周邊供應商的建議

為了與 Android 裝置互通，音訊周邊供應商應：

設計符合音訊類別規範；目前 Android 指定的類別為 1，但建議您規劃為 2 類
避免異常現象
測試與參考和熱門 Android 裝置的相容性
清楚說明支援的功能、音訊類別相容性、電源需求等資訊，讓消費者在充分瞭解相關資訊的情況下決定是否要購買

給 Android 裝置原始設備製造商 (OEM) 和 SoC 供應商的建議

為了支援 USB 數位音訊，裝置原始設備製造商和 SoC 供應商應：

設計支援 USB 主機模式的硬體
透過 android.hardware.usb.host.xml 功能旗標在架構層級啟用通用 USB 主機支援
啟用所有必要的核心功能：USB 主機模式、USB 音訊、等時傳輸模式
隨時掌握最新的核心版本和修補程式；儘管類別相容性是崇高的目標，但仍有現有的音訊外接裝置具有異常，而最新的核心版本已針對此類異常提供解決方法
啟用 USB 音訊政策，如下所述
在 device.mk 中將 audio.usb.default 新增至 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 驗證器測試」。