template <>
class WireSyncClientImpl
Defined at line 2656 of file fidling/gen/sdk/fidl/fuchsia.hardware.audio.signalprocessing/fuchsia.hardware.audio.signalprocessing/cpp/fidl/fuchsia.hardware.audio.signalprocessing/cpp/wire_messaging.h
Methods to make a sync FIDL call directly on an unowned handle or a
const reference to a |::fidl::ClientEnd
<
::fuchsia_hardware_audio_signalprocessing::SignalProcessing>|,
avoiding setting up a client.
Public Methods
::fidl::WireResult< ::fuchsia_hardware_audio_signalprocessing::SignalProcessing::GetElements> GetElements ()
Returns a vector of supported processing elements.
This vector must include one or more processing elements.
Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.
::fidl::WireResult< ::fuchsia_hardware_audio_signalprocessing::SignalProcessing::WatchElementState> WatchElementState (uint64_t processing_element_id)
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`.
Allocates 24 bytes of request buffer on the stack. Response is heap-allocated.
::fidl::WireResult< ::fuchsia_hardware_audio_signalprocessing::SignalProcessing::GetTopologies> GetTopologies ()
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.
Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.
::fidl::WireResult< ::fuchsia_hardware_audio_signalprocessing::SignalProcessing::WatchTopology> WatchTopology ()
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.
Allocates 56 bytes of message buffer on the stack. No heap allocation necessary.
::fidl::WireResult< ::fuchsia_hardware_audio_signalprocessing::SignalProcessing::SetTopology> SetTopology (uint64_t topology_id)
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.
Allocates 56 bytes of message buffer on the stack. No heap allocation necessary.
::fidl::WireResult< ::fuchsia_hardware_audio_signalprocessing::SignalProcessing::SetElementState> SetElementState (uint64_t processing_element_id, ::fuchsia_hardware_audio_signalprocessing::wire::SettableElementState state)
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.
Allocates 32 bytes of response buffer on the stack. Request is heap-allocated.