class SignalProcessing

Returns a vector of supported processing elements.

This vector must include one or more processing elements.

Get the processing element state via a hanging get.

For a given `processing_element_id`, the driver will immediately reply to the first

`WatchElementState` sent by the client. The driver will not respond to subsequent client

`WatchElementState` calls for that `processing_element_id` until any portion of the

`ElementState` has changed from what was most recently reported for that element.

The driver will close the protocol channel with an error of `ZX_ERR_INVALID_ARGS`, if

`processing_element_id` does not match an ElementId returned by `GetElements`.

The driver will close the protocol channel with an error of `ZX_ERR_BAD_STATE`, if this

method is called again while there is already a pending `WatchElementState` for this client

and `processing_element_id`.

Returns a vector of supported topologies.

This vector must include one or more topologies.

If more than one topology is returned, then the client may select any topology from the

list by calling `SetTopology`.

If only one topology is returned, `SetTopology` can still be called but causes no change.

Each Element must be included in at least one Topology, but need not be included in every

Topology.

Get the current topology via a hanging get.

The driver will immediately reply to the first `WatchTopology` sent by each client.

The driver will not respond to subsequent `WatchTopology` calls from that client until the

signal processing topology changes; this occurs as a result of a `SetTopology` call.

The driver will close the protocol channel with an error of `ZX_ERR_BAD_STATE`, if this

method is called again while there is already a pending `WatchTopology` for this client.

Sets the currently active topology by specifying a `topology_id`, which matches to an entry

in the vector returned by `GetTopologies`.

The currently active topology is communicated by `WatchTopology` responses. To change which

topology is active, a client uses `SetTopology`.

If `GetTopologies` returns only one `Topology`, `SetTopology` is optional and has no effect.

This call will fail and return `ZX_ERR_INVALID_ARGS` if the specified `topology_id` is not

found within the`topologies` returned by `GetTopologies`.

`SetTopology` may be called before or after non-`SignalProcessing` protocol calls.

If called after non-`SignalProcessing` protocol calls, then `SetTopology` may return

`ZX_ERR_BAD_STATE` to indicate that the operation can not proceed without renegotiation of

the driver state. See `SetElementState` for further discussion.

Controls the processing element specified by `processing_element_id`, a unique ElementId

returned by `GetElements`.

The `state` specified in calls to `SetElementState` is a `SettableElementState`. This is a

subset of `ElementState` because some fields returned by `WatchElementState` (e.g. `latency`

or `plug_state`) can only be observed (not set) by the client.

Returns `ZX_ERR_INVALID_ARGS` if `processing_element_id` does not match a known ElementId

returned by `GetElements`, or if `state` is not valid for the element. This entails any

violation of the rules specified in this protocol.

Examples:

`state` specifies that an element should be stopped or bypassed, but the corresponding

element does not specify (or explicitly set to false) `can_stop` or `can_bypass`.

`state` includes a `type_specific` entry, but that `SettableTypeSpecificElementState` does

not match the `ElementType` of the element corresponding to `processing_element_id`.

`state` changes an `EqualizerBandState` for an `EQUALIZER` element (so far so good), but

specifies a change to `frequency` when this element did not set `CAN_CONTROL_FREQUENCY`

in its `supported_controls`.

`state` specifies a `GainElementState` for a `GAIN` element with a `gain` value that is

-infinity, NAN, or outside the Element's stated [`min_gain`, `max_gain`] range.

Callers may intersperse method calls to the `SignalProcessing` protocol with calls to other

driver protocols. Some non-`SignalProcessing` configuration changes may require a

renegotiation of the driver state before certain elements can receive a `SetElementState`.

For example, if a `DaiFormat` is changed, then `SetElementState` changing an `AGL` element's

parameters may not require renegotiation of driver state because changing gain parameters

usually does not change the set of supported audio formats.

By contrast, following the same `DaiFormat` change, before `SetElementState` can be called

on a `CONNECTION_POINT` element, the driver state may need to be reestablished because the

format change may invalidate the set of supported formats returned in a previous

`GetDaiFormats` protocol call for another part of the Topology.

It is the driver's job to determine when renegotiation is required. When this is needed,

the related `SetElementState` call must return `ZX_ERR_BAD_STATE` and the client must

close the protocol channel entirely, such that the protocol negotiations are started over.

The client then must re-invoke the `SetElementState` call that returned

`ZX_ERR_BAD_STATE` before any non-`SignalProcessing` protocol calls.