class WireSyncClientImpl

template <>

class WireSyncClientImpl

Defined at line 883 of file fidling/gen/sdk/fidl/fuchsia.audio.device/fuchsia.audio.device/cpp/fidl/fuchsia.audio.device/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_audio_device::RingBuffer>|,

avoiding setting up a client.

Public Methods

::fidl::WireResult< ::fuchsia_audio_device::RingBuffer::SetActiveChannels> SetActiveChannels (::fuchsia_audio_device::wire::RingBufferSetActiveChannelsRequest RingBufferSetActiveChannelsRequest)

Request that specific individual channels be powered down/up, if the

device supports this. This is intended for idle power conservation.

Channels are specified by bitmask; the least significant bit corresponds

to channel 0. Each bit not set indicates that the channel can be

deactivated. `SetActiveChannels` does not change how a ring buffer

responds to `Start`/`Stop`, specifically with regards to position.

Devices are not required to obey `SetActiveChannels`. For example, they

are not required to zero-out an input stream's inactive channels, and

data written to inactive channels of an output stream's ring buffer may

still be played.

If not called, then by default all channels will be active.

Allocates 48 bytes of request buffer on the stack. Response is heap-allocated.

::fidl::WireResult< ::fuchsia_audio_device::RingBuffer::Start> Start (::fuchsia_audio_device::wire::RingBufferStartRequest RingBufferStartRequest)

Start the ring buffer, beginning at the first frame of the ring buffer.

Allocates 32 bytes of request buffer on the stack. Response is heap-allocated.

::fidl::WireResult< ::fuchsia_audio_device::RingBuffer::Stop> Stop (::fuchsia_audio_device::wire::RingBufferStopRequest RingBufferStopRequest)

Stop the ring buffer.

Allocates 32 bytes of request buffer on the stack. Response is heap-allocated.

::fidl::WireResult< ::fuchsia_audio_device::RingBuffer::WatchDelayInfo> WatchDelayInfo ()

Request delay information via a hanging get. The RingBuffer will respond

immediately to the first `WatchDelayInfo` call. Subsequent calls will

only be completed when the delay info has changed from previously

communicated values.

Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.