總覽
音訊複合驅動程式可能會使用訊號處理介面。這個介面 SignalProcessing 是 Composite 通訊協定使用的 FIDL 通訊協定,可提供音訊信號處理功能。
SignalProcessing 通訊協定定義用於控制訊號處理硬體及其拓撲。我們將處理元素 (PE) 定義為音訊驅動程式庫提供的音訊資料處理邏輯單元,並將拓撲定義為管道中的 PE 排列方式,以及與其相關聯的控制項。
硬體供應商可透過 SignalProcessing 通訊協定實作具有穩定應用程式二進位介面 (ABI) 的驅動程式,系統整合人員則可使用這些介面進行執行階段設定,根據系統或產品需求設定驅動程式的執行方式。
SignalProcessing 通訊協定會組成 Reader 信號處理通訊協定。僅擷取資訊的信號處理方法屬於 Reader 通訊協定,其餘則屬於 SignalProcessing 通訊協定本身。如果用戶端需要為自己的用戶端提供唯讀功能子集,就可以透過這種分離方式,將 Reader 信號處理通訊協定組合到自己的通訊協定中。
SignalProcessing 通訊協定和相關定義屬於 fuchsia.hardware.audio.signalprocessing FIDL 程式庫。
拓撲
每個驅動程式庫都可以有自己的拓撲。驅動程式可視特定設定或產品的需求,從應用程式中抽象化其他驅動程式公開的拓撲。請注意,雖然不一定要向應用程式 (尤其是 audio_core) 公開拓撲,但可以這麼做。
注意:
- 拓撲並非用於完整說明每個 PE 的音訊管道狀態/格式/設定。目的是根據用戶端的知識、設定 (例如來自中繼資料) 和特定商業邏輯,說明用戶端可變更/重新排列的內容。
- 拓撲包含一或多個
RingBuffer類型的處理元素 (僅限驅動程式庫支援環形緩衝區時)。 - 拓撲包含一或多個
DaiInterconnect類型的處理元素 (僅限驅動程式庫支援 DAI 互連時)。*如果 (且僅在) 驅動程式庫支援封包串流,拓撲會包含一或多個PackeetStream類型的處理元素。 - 拓撲必須包含至少一種這類元素。
處理元素
PE (在 fuchsia.hardware.audio.signalprocessing FIDL 程式庫中定義為 Element) 應為特定驅動程式庫管理的硬體提供功能 (但也可以在軟體中模擬,如同任何其他驅動程式庫程式功能)。管道由一或多個 PE 組成,拓撲則由一或多個管道組成。
我們將伺服器稱為提供訊號處理通訊協定的驅動程式庫。我們將用戶端視為功能使用者,例如 audio_core 等應用程式。
基本操作
用戶端負責要求及設定任何信號處理功能。
伺服器回覆用戶端的 GetElements 後,用戶端可能會發出 WatchElementState 呼叫 (請參閱暫止的 get 模式),以擷取 PE 狀態,並SetElementState視需要動態控制 PE 參數。舉例來說,如要擷取 type GAIN 的 gain,用戶端會發出 WatchElementState 呼叫,其中一個呼叫用於擷取初始狀態 (驅動程式庫會回覆用戶端傳送的第一個 WatchElementState),後續呼叫則用於接收 ElementState 的更新通知,其中包含 gain。同樣地,如要擷取由 bands_state 中多個頻帶組成的 PE type EQUALIZER 狀態,用戶端會發出 WatchElementState,擷取初始狀態 (驅動程式庫會回覆用戶端傳送的第一個 WatchElementState),包括每個頻帶的 frequency 欄位。
此外,伺服器回覆用戶端的 GetElements 並提供 PE 後,用戶端可能會使用 GetTopologies 方法要求可用拓撲。如果 GetTopologies 傳回多個拓撲,則 SetTopology 可用於挑選要使用的拓撲,而 WatchTopology 可用於觀察作用中拓撲的更新。
GetElements
GetElements 可選擇性取得所有 PE 的清單。舉例來說,用戶端可能會在抽象化硬體轉碼器的驅動程式庫上呼叫這個方法。用戶端得知 PE 清單後,即可根據 PE 類型公開的參數設定 PE。
SetElementState
SetElementState 可讓用戶端使用 GetElements 傳回的 ID 控制 PE 的狀態。不同類型的 PE 可能會向用戶端公開不同狀態,SetElementState 參數 state 的類型會因 PE 類型而異。
WatchElementState
用戶端可使用 GetElements 傳回的 ID 監控 PE 的狀態。WatchElementState不同類型的 PE 可能會向用戶端公開不同的狀態,WatchElementState 參數 state 的類型會因 PE 類型而異。
PE 的 state 由值組成,用戶端可透過呼叫 SetElementState 直接變更這些值,或間接變更 (例如在不同的 PE 上呼叫 SetElementState),或獨立於用戶端 (例如因外掛程式偵測變更)。
GetTopologies
GetTopologies 可讓您選擇性取得拓撲清單。舉例來說,這個方法可能會由驅動程式庫上的用戶端呼叫,以抽象化硬體轉碼器。用戶端得知拓撲清單後,即可設定伺服器使用特定拓撲。
SetTopology
SetTopology 可讓用戶端控管伺服器使用的拓撲。一次只能選取一個拓撲。
WatchTopology
WatchTopology 可讓用戶端透過暫止的 GET 觀察目前有效的拓撲 ID,並在拓撲變更時非同步接收通知。
處理元素類型
GetElements 傳回的 PE 支援多種不同類型的信號處理,這些類型由 PE 類型和參數定義。PE 類型會定義標準信號處理 (例如 GAIN、
DELAY、EQUALIZER 等)、廠商專屬信號處理 (例如 VENDOR_SPECIFIC,即 SignalProcessing 通訊協定中未定義的類型),以及用於建構多管道拓撲的 CONNECTION_POINT (允許轉送和混合定義,請參閱下方的「連線點」)。
每個 PE 可能有一或多個輸入和一或多個輸出管道。為了進行路徑設定和混音,PE 可能會讓輸出聲道數與輸入聲道數不同。
PE 可能會變更每個管道中的資料 (即處理的信號)。舉例來說,如果管道中只有一個 AGL 類型的 PE,且包含 DaiFormat number_of_channels 設為 2 的 DAI_INTERCONNECT 元素,則用戶端呼叫 SetElementState 時,可將 state started 設為 true (或設為 false,如果 AGL Element 的 can_stop 為 true),為這 2 個管道啟動或停止 AGL (自動增益限制)。
如果未納入不同 PE 類型中的選填欄位,處理元素狀態不會因特定欄位而改變。舉例來說,如果 SetElementState 呼叫中的 EqualizerBandState 未包含選用的 frequency,等化器的頻帶頻率狀態就不會變更。
廠商專屬資料
ElementState vendor_specific_data 是選用參數,可為任何處理元素指定。處理元素可藉此指定不透明物件,以便傳送至驅動程式庫 (做為 SetElementState 的一部分),或從驅動程式庫接收 (做為 WatchElementState 的一部分)。
除了任何類型的不透明資料,VENDOR_SPECIFIC 類型的處理元素也允許驅動程式指定 SignalProcessing 通訊協定中未定義的類型,例如尚未標準化或不打算標準化,且僅由特定供應商提供的類型。VENDOR_SPECIFIC 類型的處理元素會在 TypeSpecificElement 和 TypeSpecificElementState 中指定 vendor_specific 變體。此外,它可能會指定要使用 ElementState
vendor_specific_data 參數傳送至或接收自驅動程式庫的不透明資料,就像任何其他處理元素類型一樣。
拓撲
GetTopologies 傳回的拓撲支援 GetElements 傳回的 PE 不同排列方式。GetTopologies 可以宣傳一或多個拓撲。
一個拓撲
如果宣傳的是一個拓撲,也就是 GetTopologies 會傳回含有一個元素的向量,則所有 PE 都屬於這個明確的單一管道。本例中的排序方式為明確排序。舉例來說,如果 GetElements 傳回 2 個 PE:
Element:id = 1,type =AUTOMATIC_GAIN_LIMITER(AGL)Element:id = 2,type =EQUALIZER(EQ)
GetTopologies 傳回的單一 Topology 元素會列出 id 和 processing_elements_edge_pairs 向量,明確宣傳訊號處理的執行順序,在本例中為:
Topology:id = 1,processing_elements_edge_pairs= 向量,其中一個元素具有processing_element_id_from= 1 和processing_element_id_to= 2。
這會透過一個管道宣傳這個拓撲:
+-------+ +-------+
Input signal -> | AGL | -> | EQ | -> Output signal
+-------+ +-------+
在這個拓撲中,管道的開頭 (輸入訊號輸入管道的位置) 和結尾 (輸出訊號從管道輸出的位置) 是隱含的。
如果只宣傳一種拓撲,則內容僅供參考,因為用戶端無法變更使用單一拓撲。
多個拓撲
如果播送多個拓撲 (即 GetTopologies 傳回含有多個元素的向量),則 PE 可能會用於多個設定 (即拓撲)。每個拓撲都會明確列出 PE 數量及其順序,也就是說,此案例中的順序是明確的。PE 的排列方式和順序會定義管道。
伺服器只會列出支援的特定 PE 配置和順序,藉此限制管道的有效組合。
舉例來說,如果 GetElements 傳回 6 個 PE:
Element:id = 1,type =AUTOMATIC_GAIN_LIMITER(AGL)Element:id = 2,type =EQUALIZER(EQ)Element:id = 3,type =SAMPLE_RATE_CONVERSION(SRC)Element:id = 4,type =GAINElement:id = 5,type =DYNAMICS(DRC1)Element:id = 6,type =DYNAMICS(DRC2) 參數與 DRC1 參數不同。
GetTopologies 傳回的 Topology 元素會列出每個拓撲的 id 和 processing_elements_edge_pairs,在本例中:
Topology:id = 1,processing_elements_edge_pairs=processing_element_id_from= 3,而processing_element_id_to= 2。processing_element_id_from= 2 且processing_element_id_to= 4。processing_element_id_from= 4,而processing_element_id_to= 5。processing_element_id_from= 5 且processing_element_id_to= 1。
Topology:id = 2,processing_elements_edge_pairs=processing_element_id_from= 2 且processing_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 可提供以下功能:
- 在單一管道中混合多個管道。
- 混合來自不同管道的多個聲道。
- 重複的頻道。
- 將單一管道擴展為多個管道 (分散)。