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

USB 數位音訊

本文將介紹 Android 支援的 USB 數位音訊和相關以 USB 為基礎的通訊協定。

目標對象

本文的目標對象為 Android 裝置的原始設備製造商 (OEM) 或 SoC 供應商 USB 音訊週邊裝置供應商、進階音訊應用程式開發人員以及有其他參與者進一步瞭解 Android 上的 USB 數位音訊內部。

Nexus 裝置的使用者請參閱本文使用 USB 主機模式錄製及播放音訊的請改為參閱 Nexus 說明中心。雖然本文並非以使用者為主某些樂迷可能會找到一些感興趣的內容。

USB 總覽

通用串列匯流排 (USB) 是在維基百科文章中非正式的說明 USB 是依照 USB 應用廠商論壇, Inc。為方便起見，我們歸納了這裡的主要 USB 概念但標準為官方參考資料

基本概念和術語

USB 是一種公車由單一資料移轉作業發起者稱為「主機」。主機會與週邊裝置。

注意：「裝置」和「配件」這兩個字詞是下列的常見同義詞： 週邊裝置。我們不會在這裡排除這些字詞，因為可能會混淆 Android 裝置或是 Android 專屬概念配件模式。

關鍵主機角色為「列舉」：偵測哪些週邊裝置已連接到匯流排以及查詢透過描述元表示的屬性。

週邊裝置可以是一個實體物件但實際上是實作多個邏輯「函式」舉例來說，網路攝影機週邊裝置可能同時具備相機功能和麥克風音訊功能

每個週邊裝置都有一個「介面」，定義與該函式通訊的通訊協定。

主機會透過直立線附加至端點做為資料來源或接收器透過其中一項週邊裝置的函式。

管道分為兩種：message 和 stream。訊息管道用於雙向控制和狀態。串流管道用於單向資料移轉。

主機會啟動所有資料移轉作業因此，「input」和「output」這兩個字詞都會與主機表示。輸入作業會從週邊裝置將資料轉移至主機輸出作業則會將資料從主機傳輸到週邊裝置。

資料移轉主要有三種：中斷、大量和同位素。我們會在音訊環境中進一步討論獨立模式。

週邊裝置可能包含連至外界的「終端機」，而非週邊裝置本身這樣一來，週邊裝置，可在 USB 通訊協定和「實際」兩者間進行轉譯信號終端是函式的邏輯物件。

Android USB 模式

開發模式

開發模式自 Android 首次發布以來一直存在。 Android 裝置會顯示為 USB 週邊裝置下載至執行電腦作業系統 (如 Linux) 的主機電腦 Mac OS X 或 Windows唯一可見的周邊裝置函式為 Android 快速啟動或 Android Debug Bridge (ADB)。 Fastboot 和 ADB 通訊協定分層在 USB 大量資料移轉模式上。

主機模式

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

由於 Android 裝置必須扮演主機，而大多數 Android 裝置都會具備不會直接允許主機操作的 micro-USB 連接器。行動 (OTG) 變壓器比如，這通常為必要項目：

圖 1. 行動支付 (OTG) 變壓器

Android 裝置提供的電量可能不足以運作視週邊裝置需求量而定以及 Android 裝置的供應量即使電量充足，Android 裝置的電池充電通常會大幅縮短在這種情況下，請使用 Hub，如下所示：

圖 2. 供電中樞裝置

配件模式

配件模式是在 Android 3.1 (API 級別 12) 中推出，向後移植至 Android 2.3.4。在這個模式下，Android 裝置會做為 USB 週邊裝置運作，。開發模式和配件模式之間的差異就是 ADB 以外的主機可以看到額外的 USB 函式。 Android 裝置進入開發模式，然後才會改採配件模式

在 Android 4.1、。

USB 音訊

USB 類別

每個週邊裝置函式都有相關聯的裝置類別文件，指定該函式的標準通訊協定。這可提供符合課程規範的主機和周邊功能互通操作，不需要對彼此做過作業的詳盡知識。如果主機和周邊裝置是由不同的實體

「駕駛」是「符合類別」的常見同義詞。表示您可以使用這類且不必指定作業系統待安裝 driver。可以假設所宣傳的周邊裝置「無需駕駛人」常見的電腦作業系統即符合本期規定，但可能會有例外。

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 微秒，而且速度相當快每個完整速度的影格最多包含 1,023 個位元組的酬載高速影格最多會承載 1,024 個位元組總結來說我們將最高轉移率計算為 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 裝置會做為主機 (例如座架) 的資料來源。

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

Android 裝置必須由具備知識的主機控管，且就能先將 Android 裝置從開發模式轉換至配件模式主機必須從適當的端點傳輸音訊資料因此 Android 裝置並非以「駕駛模式」顯示傳送到主機
方向必須是 input (相對於主機)
音訊格式必須為 16 位元 PCM
取樣率必須為 44.1 kHz
聲道數必須為 2 (立體聲)

配件模式音訊功能並未廣泛採用且目前不建議設計新設計。

USB 數位音訊應用程式

顧名思義，它的代表 USB 數位音訊訊號數位資料串流而非類比一般 TRS Mini 使用的信號耳機連接器。最終任何數位信號都必須轉換成類比才能聽見。選擇轉換的位置有利於取捨。

兩位 DAC 的故事

在下方的範例圖表中，我們比較了兩種設計。首先是安裝了 App Processor (AP)、內建 DAC、擴大器和類比 TRS 連接器連接了耳機。我們也會考量使用 USB 連接外部 USB DAC 和擴大器的行動裝置也支援耳機

圖 3. 比較兩個 DAC

哪一種設計比較好？答案取決於您的需求。每種方式各有優缺點。

注意：這是人工比較資料，因為那麼實體的 Android 裝置或許會同時提供這兩種選項。

第一個設計 A 較簡單、費用較低、耗電量較低並以同樣可靠的元件為前提，讓設計更穩定。不過，比起其他規定，音質通常要有所取捨。舉例來說，如果產品為大眾行銷產品，也就是一般消費者的需求而非純粹對音響系統的需求

第二種設計則是讓外部音訊週邊裝置 C 提高音訊品質和充電功率，且不影響最基本的 Android 裝置 B是的，它的設計比較昂貴但只有有需要的人才會吸收

行動裝置對於高密度裝置感到不利電路板可以為電路板跟蹤降低相鄰的類比訊號降低音量。數位通訊較不容易噪音、因此將 DAC 從 Android 裝置 A 移到外部電路板 C 可以讓最終的類比階段在物理和電動過程中與稠密、嘈雜的電路板隔離，以提升音質。

另一方面第二種設計比較複雜，且複雜度越高，越複雜讓企業無法負荷也可能會造成額外延遲。

主機模式應用程式

一般 USB 主機模式音訊應用程式包括：

聽音樂
電話通訊系統
即時通訊和語音通訊
錄製中

Android 偵測到上述所有應用程式音訊週邊裝置，以及自動轉送音訊播放和擷取以適當方式處理音訊立體聲內容是在周邊裝置的前兩個頻道播放。

USB 數位音訊沒有專用的 API。使用進階功能時，自動轉送功能可能會幹擾應用程式能偵測 USB 感知的請為這類應用程式停用自動轉送功能點選 [媒體] 部分中的對應控制項設定 / 開發人員選項。

在主機模式下進行偵錯

處於 USB 主機模式時，無法透過 USB 進行 ADB 偵錯。請參閱「無線用量」一節 / Android Debug Bridge 。

實作 USB 音訊

給音訊週邊裝置供應商的建議

為了與 Android 裝置互通操作，音訊週邊裝置供應商應採取下列步驟：

音訊類別的法規遵循設計；目前 Android 指定類別 1，但建議針對類別 2 進行規劃
避免搞怪
測試與參考用熱門 Android 裝置的互通性
清楚說明支援的功能、音訊類別規範、電源需求等，在充分瞭解資訊的情況下

Android 裝置原始設備製造商 (OEM) 和 SoC 供應商推薦項目

如要支援 USB 數位音訊，裝置原始設備製造商 (OEM) 和 SoC 供應商應：

設計硬體，支援 USB 主機模式
在架構層級啟用一般 USB 主機支援透過 android.hardware.usb.host.xml 功能旗標
啟用所需的所有核心功能：USB 主機模式、USB 音訊、異議傳輸模式；請參閱「Android 核心設定」
及時更新核心版本和修補程式；儘管達到集體標準的目標，但其實仍有音訊週邊裝置和奇怪，許多近期核心都有辦法解決問題
按照以下說明啟用 USB 音訊政策
將 audio.usb.default 加入 device.mk 中的「PRODUCT_PACKAGES」
測試與常見 USB 音訊週邊裝置的互通性

啟用 USB 音訊政策

如要啟用 USB 音訊，請在音訊政策設定檔。這通常位置：

device/oem/codename/audio_policy.conf

pathname 元件「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
      }
    }
  }
  ...
}

原始碼

音訊硬體抽象層 (HAL) USB 音訊實作的位置如下：

hardware/libhardware/modules/usbaudio/

USB 音訊 HAL 非常仰賴 tinyalsa，請參閱「音訊術語」一文。雖然 USB 音訊支援異測傳輸而這完全由 ALSA 實作負責。所以您無需擔心 USB 音訊 HAL 和 tinyalsa 使用這個階段的 USB 通訊協定

測試 USB 音訊

如要進一步瞭解 USB 音訊的 CTS 測試，請參閱 USB 音訊 CTS 驗證器測試。