class WireSyncClientImpl

Creates a Producer node with the given options.

Producer nodes generate audio which can be consumed by other nodes. For

example, a Producer node might encapsulate audio coming from an

application or from a microphone. Producer nodes cannot have any

incoming edges and may have at most one outgoing edge.

Request is heap-allocated. Response is heap-allocated.

Creates a Consumer node with the given options.

Consumer nodes write audio to a sink. For example, a Consumer node might

encapsulate audio being written to a speaker or to an application (which

may be capturing audio from a microphone). Consumer nodes can have at

most one incoming edge.

Audio pipelines are driven by Consumers. Each Consumer is attached to a

Thread, which gives the Consumer a place to do work. A Consumer wakes

every `N` ms (`N` is configurable), pulls `N` ms of audio from its

incoming edge, then writes that audio to the Consumer's sink.

For more details, see "Execution Model" under the description for

[`Graph`].

Request is heap-allocated. Response is heap-allocated.

Creates a Mixer node with the given options.

Mixer nodes combine multiple PCM source streams into a single PCM

destination stream. Mixers apply format conversion and sample rate

conversion to the source streams to produce a destination stream with a

fixed format.

Request is heap-allocated. Response is heap-allocated.

Creates a Splitter node with the given options.

Splitter nodes copy a single source stream into multiple destination

streams. Each Splitter node has a hidden Consumer node which is

responsible for pulling data from the Splitter's source and writing that

data to an intermediate buffer. Destination streams read directly from

this buffer. For more details on this behavior, see "Execution Model"

under the description for [`Graph`].

Each Splitter is assigned to a thread which drives the hidden Consumer's

work to fill the intermediate buffer. Destination streams can be

assigned to any thread. If a destination stream is assigned to the same

thread as the Splitter, that stream can copy the Splitter's source

stream without any additional latency. If a destination stream is

assigned to a different thread T, then extra buffering is required to

avoid data races -- that extra buffering adds additional latency of

`T.period`.

Current limitation: The Splitter does not fill its intermediate buffer

unless it has at least one destination stream that is started and that

is assigned to the same thread as the Splitter. This limitation may be

lifted at a future time.

Request is heap-allocated. Response is heap-allocated.

Creates a Custom node with the given options.

Custom nodes apply custom effects to one or more source streams,

producing one or more destination streams. The effects are implemented

out-of-process via a call to a FIDL interface.

Custom nodes are composite nodes that encapsulate a fixed number of

sources and destinations. We assign an ID to each of these source and

destination slots -- see [`CustomNodeProperties`]. This allows creating

edges that target a specific slot. For example, a node that implements

AEC will have loopback and microphone source slots and the caller will

need to connect each source slot to an appropriate source. The caller

can do this by calling `CreateEdge` using a specific [`NodeId`] from

[`CustomNodeProperties.source_ids`]. These internal IDs cannot be

deleted, except by deleting the entire Custom node.

The returned `id` describes the composite node. Passing `id` to

[`DeleteNode`] will delete the composite node as well as any internal

source and destination nodes. The returned `id` cannot be used in

[`CreateEdge`]. Edges must target a specific source or destination slot

as described above.

Request is heap-allocated. Response is heap-allocated.

Deletes the given node.

The node must exist. `DeleteNode(x)` will delete all incoming and

outgoing edges of node `x` before deleting the node itself. Once the node

has been deleted it cannot be mentioned by any future method calls.

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

Creates an edge from the source node to the destination node.

Both nodes must exist. The source's format must be supported by the

destination node. Mixer nodes support arbitrary source formats. Other

nodes support only specific (fixed) source formats.

Both ends must use the same reference clock, unless the destination is a

Mixer, in which case the source can use any clock.

If the source's direction is `INPUT`, the dest's direction cannot be

`OUTPUT`. See [`PipelineDirection`] for additional discussion.

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

Deletes the edge connecting the source node to the destination node.

The edge must exist.

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

Creates a thread.

Each `CreateThread` call creates a new thread in the mixer service. This

new thread will be used to process audio for all Consumer nodes assigned

to this thread.

For more details, see "Execution Model" under the description for

[`Graph`].

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

Deletes the given thread.

The thread must exist. A thread cannot be deleted until all Consumer

nodes assigned to that thread have been deleted.

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

Creates a GainControl.

A GainControl controls gain that should be applied to an audio stream.

GainControls can be attached to edges going into and out of a Mixer node.

Gain can be set to a specific value (e.g. in decibels) or it can be

muted.

By default, a GainControl applies no gain and is not muted.

Request is heap-allocated. Response is heap-allocated.

Deletes the given GainControl.

The GainControl must exist. A GainControl cannot be deleted until all

associated edges have been deleted.

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

Creates a graph-controlled reference clock.

The returned clock has `ZX_RIGHT_READ` and `ZX_RIGHT_DUPLICATE` but not

`ZX_RIGHT_WRITE`. The clock may be duplicated and used wherever a

reference clock is needed. The graph will rate change this clock until

the `release_fence` is closed.

For more details, see "Clocks" under the description for [`Graph`].

* error Error from `zx_clock_create`

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

Starts a consumer or a producer at a specified time.

When a call to this method succeeds, the response is typically sent when

the operation actually occurs (that is, when it was scheduled to occur),

but may complete sooner. When a call to this method fails, the response

is sent when the failure is detected.

If this method is called, and `when` specifies a time in the past, the

stream timeline is started as soon as possible.

If a `Start` or `Stop` request is received when a previous `Start` or

`Stop` request is pending, the connection is closed. This request can be

canceled using the `CancelStartOrStop` method.

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

Stops a consumer or a producer at a specified time.

When a call to this method succeeds, the response is typically sent when

the operation actually occurs (that is, when it was scheduled to occur),

but may complete sooner. When a call to this method fails, the response

is sent when the failure is detected.

If this method is called when the stream timeline is stopped, the call

fails immediately with an `ALREADY_STOPPED` error.

Otherwise, if this method is called, and `when` specifies a time in the

past, the stream timeline is stopped as soon as possible.

If a `Start` or `Stop` request is received when a previous `Start` or

`Stop` request is pending, the connection is closed. This request can be

canceled using the `CancelStartOrStop` method.

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

Cancels the previously-received `Start` or `Stop` request if it is still

pending. Cancel requests race with the pending operations they are

intended to cancel. The response to the request to be canceled indicates

the outcome of the race. In typical usage, a `CancelStartOrStop` request

should be followed in short order by a `Stop` or `Start` request so that

the state of the service is known.

Allocates 80 bytes of message buffer on the stack. No heap allocation necessary.

Reports a producer's lead time. In output pipelines, a producer's lead

time defines how early an audio frame must be received in order for that

frame to be presented on time. If a client wishes to present an audio

frame at time T, that frame must be delivered to this producer by time

`T - LeadTime`.

Allocates 88 bytes of message buffer on the stack. No heap allocation necessary.