音訊訊號處理

總覽

音訊合成驅動程式可以使用訊號處理介面。這個介面 SignalProcessing 是 Composite 通訊協定所使用的 FIDL 通訊協定，可提供音訊訊號處理功能。

我們定義了 SignalProcessing 通訊協定，用來控制訊號處理硬體及其拓撲。我們將處理元素 (PE) 定義為音訊驅動程式庫提供的音訊資料處理邏輯單位，而我們將拓撲定義為管道中的 PE 排列方式，以及與這些元素相關聯的控制權。

SignalProcessing 通訊協定可讓硬體供應商實作具備穩定的應用程式二進位檔介面 (ABI) 的驅動程式，並允許系統整合商根據系統或產品需求，針對執行階段設定，根據系統或產品需求設定驅動程式以不同方式執行。

SignalProcessing 通訊協定會組成 Reader 信號處理通訊協定。僅擷取資訊的信號處理方法屬於 Reader 通訊協定的一部分，其餘部分屬於 SignalProcessing 通訊協定。透過這種區隔方式，如果此介面的用戶端需要向其用戶端提供功能子集，則可將 Reader 信號處理通訊協定組合成自己的通訊協定。

SignalProcessing 通訊協定和相關聯的定義屬於 fuchsia.hardware.audio.signalprocessing FIDL 程式庫的一部分。

拓撲

每個驅動程式庫皆可擁有自己的拓撲。驅動程式可以從應用程式提取其他應用程式的拓撲，以滿足特定設定或產品需要的其他驅動程式。請注意，雖然不必向應用程式公開拓撲，但不必向應用程式揭露拓撲，尤其是 audio_core。

注意：

  • 拓撲並非完整說明每個 PE 內與中的音訊管道狀態/格式/設定。這麼做的目的是說明用戶端可根據其知識、設定 (例如來自中繼資料) 及特定商業邏輯，變更/重新排列哪些項目。
  • 針對提供 Composite 通訊協定的音訊驅動程式所使用的拓撲必須包含 ENDPOINT PE，針對驅動程式庫支援的環形緩衝區和 DAI 互連網路提供 ID。

處理元素

PE (在 fuchsia.hardware.audio.signalprocessing FIDL 程式庫中定義為 Element) 預期是由特定驅動程式庫管理的硬體提供的功能 (但可能會在軟體中模擬，就像任何其他驅動程式庫功能一樣)。管道由一或多個 PE 組成，拓撲由一或多個管道組成。

我們將伺服器稱為提供信號處理通訊協定的驅動程式庫。我們將客戶稱為功能使用者，例如 audio_core 之類的應用程式。

基本作業

用戶端應負責要求及設定任何信號處理功能。伺服器透過回覆用戶端的 GetElements 提供 PE 後，用戶端可能會發出WatchElement呼叫 (請參閱掛斷取得模式) 以擷取 PE 狀態，並SetElementState視需要動態控制 PE 參數。舉例來說，如要擷取 type GAIN PE 的 gain，用戶端會發出 WatchElement 呼叫，用於擷取初始狀態 (驅動程式庫會回覆用戶端傳送的第一個 WatchElement)，之後會收到包含 gain 更新的 ElementState 通知。同樣地，如要擷取 type EQUALIZER 中由多個頻帶組成的 PE 狀態，用戶端會發出 WatchElement 來擷取初始狀態 (驅動程式庫會回覆用戶端傳送的第一個 WatchElement)，包括每個頻帶的 frequency 欄位。bands_state

伺服器透過回應用戶端的 GetElements 提供 PE 後，用戶端可能會使用 GetTopologies 方法要求可用的拓撲。如果 GetTopologies 傳回多個拓撲，您就能使用 SetTopology 挑選要使用的拓撲。

GetElements

GetElements 可讓您視需要取得完整的 PE 清單。舉例來說，在擷取硬體轉碼器的驅動程式庫上，用戶端可能會呼叫這個方法。用戶端得知 PE 清單後，用戶端即可根據 PE 類型公開的參數來設定 PE。

SetElementState

SetElementState 可讓用戶端使用 GetElements 傳回的 ID 控制 PE 的狀態。不同類型的 PE 可能會對用戶端公開不同的狀態，SetElementState 參數 state 的類型會因 PE 類型而異。

WatchElement

WatchElement 可讓用戶端使用 GetElements 傳回的 ID 監控 PE 的狀態。不同類型的 PE 可能會對用戶端公開不同的狀態，WatchElement 參數 state 的類型會因 PE 類型而異。

PE 的 state 由用戶端透過呼叫 SetElement 直接變更，或藉由呼叫其他 PE 呼叫 SetElement 來間接變更，或因插頭偵測改變而獨立於用戶端之外的情況。

GetTopologies

GetTopologies 可讓您視需要取得拓撲清單。舉例來說，用戶端可在抽象硬體轉碼器的驅動程式庫上呼叫這個方法。在用戶端得知拓撲清單後，用戶端可能會設定伺服器使用特定拓撲。

SetTopology

SetTopology 可讓用戶端控管伺服器使用的拓撲。一次只能選取一個拓撲。

處理元素類型

GetElements 傳回的 PE 支援由 PE 類型和參數定義的多種不同信號處理。PE 類型定義標準信號處理 (例如 GAIN、DELAY、EQUALIZER 等)、供應商專屬信號處理 (VENDOR_SPECIFIC，例如 SignalProcessing 通訊協定中未定義的類型) 和 CONNECTION_POINT/ENDPOINT，用來建構多管道拓撲 (適用於管道開始、結束、轉送和混合定義，請參閱下方連結點和 端點})。

每位產品專家都有一或多個輸入內容和一或多個輸出管道。如果是轉送和混合，PE 可能會使用與輸入管道數量不同的輸出通道數量。

產品專家可能會變更每個管道中的資料 (也就是處理的信號)。舉例來說，如果管道中有一個 AGL 類型的 PE，且其中包含 DAI_INTERCONNECT 類型的 ENDPOINT，且 DaiFormat number_of_channels 設為 2，則用戶端呼叫 SetElementState 並將 state enable 設為 true 或 false 時，即可啟用或停用這些 2 個管道的 AGL (自動增值限制)。Elementcan_disable

如果未包含不同 PE 類型的選填欄位，則處理元素的狀態不會隨特定欄位而變更。舉例來說，如果 SetElement 中的 EqualizerBandState 不包含選用的 frequency，則不會變更等化器的頻帶頻率狀態。

供應商專屬資料

ElementState vendor_specific_data 是可針對任何處理元素指定的選用參數。這可讓處理元素指定不透明物件，該物件可傳送至 SetElementState 的驅動程式部分，或做為 WatchElementState 的一部分，由驅動程式庫接收。

除了任何類型的不透明資料外，VENDOR_SPECIFIC 類型的處理元素還可讓駕駛人指定未在 SignalProcessing 通訊協定中定義的類型，例如尚未標準化或僅供特定廠商提供的標準類型項目。VENDOR_SPECIFIC 類型的處理元素不會指定任何 TypeSpecificElement 參數，而是使用 ElementState vendor_specific_data 參數，指定與驅動程式庫傳送或接收的不透明資料，與其他處理元素類型相同。

拓撲

GetTopologies 傳回的拓撲為 GetElements 傳回的 PE 支援不同的排列方式。GetTopologies 可能會宣傳一或多個拓撲。

一個拓撲

如果通告一個拓撲，即 GetTopologies 傳回具有一個元素的向量，則所有 PE 都會屬於這個明確單一管道的一部分。在此情況下，順序並不明確。舉例來說，如果 GetElements 傳回 2 個 PE：

  1. Element：id = 1，類型 = AUTOMATIC_GAIN_LIMITER (AGL)
  2. Element：id = 2，類型 = EQUALIZER (EQ)

GetTopologies 傳回的 Topology 元素會列出 id 和 processing_elements_edge_pairs 向量，明確公告信號處理的順序，在此範例中：

  1. Topology：id = 1，processing_elements_edge_pairs = 具有一個元素的向量，processing_element_id_from = 1，processing_element_id_to = 2。

這會透過一個管道宣傳這個拓撲：

                +-------+    +-------+
Input signal -> |  AGL  | -> +  EQ   | -> Output signal
                +-------+    +-------+

在此拓撲中，一開始 (輸入信號將輸入管道) 和管道的結束 (輸出信號是來自管道的輸出) 是隱含的。還可透過 ENDPOINT 類型的 PE 明確製作 (請參閱下方的端點)。

如果只通告一個拓撲，則由於用戶端無法變更僅使用一種拓撲，因此內容僅供參考。

多個拓撲

如果通告多個拓撲，例如 GetTopologies 傳回具有多個元素的向量，則可使用 PE 多種設定，例如拓撲。每個拓撲會明確列出一些 PE 及其順序。也就是說，在本例中，排序是明確的項目。PE 的安排和順序會定義管道。

伺服器只要列出支援的產品專家的特定安排和順序，就會限制有效的管道組合。

舉例來說，如果 GetElements 傳回 6 個 PE：

  1. Element：id = 1，類型 = AUTOMATIC_GAIN_LIMITER (AGL)
  2. Element：id = 2，類型 = EQUALIZER (EQ)
  3. Element：id = 3，類型 = SAMPLE_RATE_CONVERSION (SRC)
  4. Element：id = 4，類型 = GAIN
  5. Element：id = 5，類型 = DYNAMIC_RANGE_COMPRESSION (DRC1)
  6. Element：id = 6，類型 = DYNAMIC_RANGE_COMPRESSION (DRC2) 參數與 DRC1 參數不同。

GetTopologies 傳回的 Topology 元素會列出每個拓撲的 id 和 processing_elements_edge_pairs，範例如下：

  1. Topology：id = 1、processing_elements_edge_pairs = *.processing_element_id_from= 3 andprocessing_element_id_to= 2. *. processing_element_id_from = 2，processing_element_id_to = 4。 *.processing_element_id_from= 4 andprocessing_element_id_to= 5. *. processing_element_id_from = 5，processing_element_id_to = 1。
  2. Topology：id = 2，processing_elements_edge_pairs = *.processing_element_id_from= 2 andprocessing_element_id_to= 4. *. processing_element_id_from = 4，processing_element_id_to = 6。

這會透過一個管道通告兩個拓撲：

                +-------+    +-------+    +-------+    +-------+    +-------+
Input signal -> |  SRC  | -> +  EQ   | -> + GAIN  | -> +  DRC1 | -> +  AGL  | -> Output signal
                +-------+    +-------+    +-------+    +-------+    +-------+

                +-------+    +-------+    +-------+
Input signal -> |  EQ   | -> + GAIN  | -> +  DRC2 | -> Output signal
                +-------+    +-------+    +-------+

連接點

CONNECTION_POINT 類型的 PE 可以：

  1. 在單一管道中混合使用多個管道。
  2. 混合來自不同管道的多個管道。
  3. 重複頻道。
  4. 將單一管道擴展至多個管道管道 (散佈)。

端點

ENDPOINT 類型的 PE 為選用項目 (即使有 CONNECTION_POINT)，也能以明確的起始輸入和結束輸出來完成管道結構。不過，對於提供 Composite 通訊協定的驅動程式，任何支援的環形緩衝區或 DAI 互連網路都必須列為 ENDPOINT，且類型是由 RING_BUFFER 和 DAI_INTERCONNECT 傳回。GetElementsComposite 通訊協定 API 需要端點 PE ID，才能識別環形緩衝區和 DAI 互動設定。

如未指定 ENDPOINT，則沒有傳入邊緣的 PE 即為輸入，且沒有傳出邊緣的 PE 會輸出。舉例來說，上方多個拓撲中的範例包含兩個拓撲，每個拓撲每個都擁有一個管道，拓撲 ID 1 中的單一管道以 PE ID 3 開始、以 PE id 1 開始，而拓撲 ID 2 中的單一管道以 PE id 2 開頭，結尾為 PE ID 6。