音訊驅動程式架構

在 Fuchsia 中，驅動程式的架構方式有很多種，取決於使用的驅動程式數量、通訊方式和責任。音訊驅動程式的責任取決於向驅動程式庫程式用戶端公開的介面，用戶端可以是其他驅動程式，也可以是驅動程式設施的使用者應用程式。

定義

字詞 定義
硬體轉碼器 可將數位/類比訊號編碼/解碼為類比/數位訊號的實體或虛擬裝置，包括所有組合，例如數位訊號到數位訊號。例如 DAC 放大器組合和 ADC 轉換器。
控制器或引擎 系統中管理音訊訊號的硬體部分，例如 SOC 的音訊子系統。
DAI 數位音訊介面。音訊硬體介面，例如控制器和編解碼器之間的 TDM 或 PDM 連結。
環形緩衝區 抽象化用於資料移轉的共用記憶體區域 (在主記憶體中) 管理；這個共用記憶體區域是由 VMO 物件提供。

音訊介面

音訊驅動程式的應用程式/用戶端使用者所用的 API 是音訊複合介面。應用程式可透過這個 API 存取驅動程式公開的音訊硬體功能。驅動程式可透過一或多個 DAI，公開各種硬體的功能，包括硬體轉碼器、具有環形緩衝區和 DAI 的控制器，以及音訊訊號處理 API 允許的任何處理元素組合。

音訊硬體常見的分割方式是，音訊引擎會設定與音訊硬體轉碼器通訊的 DAI。在這種分割方式中，音訊引擎和轉碼器各有一個驅動程式庫。這兩個驅動程式都可以使用 Audio Composite Interface 公開相關功能。編解碼器驅動程式庫會公開一或多個 DAI 互連介面，音訊引擎驅動程式庫則會設定音訊引擎硬體，包括連線至編解碼器驅動程式庫程式的 DAI 或 DAI。

這些驅動程式的用戶應會設定所有驅動程式。舉例來說，如果系統有兩個不同的編解碼器，且實際連線至引擎，即可使用這個架構，例如抽象化 SoC 的音訊子系統。

                           +-----------------+
                +----------+     Client      +----------+
                |          +-----------------+          |
                |                   |                   |
          Composite API       Composite API      Composite API
                |                   |                   |
       +-----------------+ +-----------------+ +-----------------+
       | audio subsystem | |     Codec 1     | |     Codec 2     |
       +-----------------+ +-----------------+ +-----------------+

已淘汰的介面

已淘汰的介面包括：

  1. StreamConfig： 用於透過 audio_core 和 audio-驅動程式庫-ctl 擷取或算繪音訊。前者是音訊系統核心的第 1 版 (提供軟體混音、路徑等)，後者則是用於測試和啟動新平台的公用程式。

先前使用 StreamConfig API 的驅動程式，現在可透過音訊複合和一個環形緩衝區實作。

  1. 轉碼器：用於透過一個 DAI 抽象化硬體轉碼器。先前使用 Codec API 的驅動程式可透過 Audio Composite 實作，其中包含一個 DAI，且沒有環形緩衝區。

  2. DAI：用於透過一個環形緩衝區和一個 DAI 抽象化 SoC 硬體。先前使用 DAI API 的驅動程式，現在可以透過音訊複合實作，其中包含一個 DAI 和一個環形緩衝區。

虛擬音訊驅動程式

如要進行自動測試和子系統開發，虛擬音訊驅動程式會在軟體中模擬音訊硬體： * 現代化 virtual-audio 驅動程式庫會實作 Composite API。 * 舊版 virtual-audio-legacy 驅動程式庫會實作已淘汰的 StreamConfig、Dai 和 Codec API。