The signal processing interface is available to be potentially used by audio hardware codecs (from
here on referred to as 'codecs') , DAIs and glue drivers. This interface
SignalProcessing is a
FIDL protocol composed by the
SignalProcessing interface is defined to control signal processing hardware and their
topologies. We define processing elements (PEs) as a logical unit of audio data processing provided
by an audio driver, and we define topologies as the arrangement of PEs in pipelines and
controls associated with them.
SignalProcessing interface allows hardware vendors to implement drivers with stable
application binary interfaces (ABIs), and allow system integrators to configure drivers to perform
differently based on system or product requirements using these interfaces for run-time
Each driver can have its own topology. Glue drivers can abstract from applications the topologies
exposed by DAI or codec drivers as needed for a particular configuration or product. Note that it is
possible although not required to expose topologies to applications, in particular to
In cases where the topologies are static, it is not mandatory to expose the one and only topology since there is no way to change it. This is the case for simpler hardware codecs PEs.
Note that topologies are not meant to fully describe the audio pipeline state/format/configuration in and out of every PE. The intent is to describe what can be changed/rearranged by the client (for instance a glue driver) based on its knowledge, configuration (for instance from metadata) and specific business logic.
A PE is expected to be hardware-provided functionality managed by a particular driver (but it could be emulated in software, as any other driver functionality). A pipeline is composed of one or more PEs and a topology is composed of one or more pipelines.
A codec or DAI driver can expose their topology by implementing the composed
protocol. A glue driver can use
SignalProcessing functionality on the
particular product or system. Finally a
StreamConf user like
audio_core can use a
We refer to the server as the driver that is providing the signal processing protocol, e.g. a codec
or DAI driver. We refer to the client as the user of the functionality, e.g. a glue driver or an
application such as
The client is responsible for requesting and then configuring any signal processing capabilities.
GetProcessingElements allows to optionally get a list of all PEs (a server not supporting PEs may
return an empty vector). For instance this method may be called by a glue driver on a codec. Once
the list of PEs is known to the client, the client may configure the PEs based on the parameters
exposed by the PE types.