class WireWeakOnewayClientImpl

Adds a payload buffer to the current buffer set associated with the

connection. A `StreamPacket` struct reference a payload buffer in the

current set by ID using the `StreamPacket.payload_buffer_id` field.

A buffer with ID `id` must not be in the current set when this method is

invoked, otherwise the service will close the connection.

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

Removes a payload buffer from the current buffer set associated with the

connection.

A buffer with ID `id` must exist in the current set when this method is

invoked, otherwise the service will will close the connection.

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

Sends a packet to the service. This interface doesn't define how the

client knows when the sink is done with the associated payload memory.

The inheriting interface must define that.

`packet` must be valid for the current buffer set, otherwise the service

will close the connection.

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

Indicates the stream has ended. The precise semantics of this method are

determined by the inheriting interface.

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

Discards packets previously sent via `SendPacket` or `SendPacketNoReply`

and not yet released.

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

Binds to the gain control for this AudioRenderer.

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

Sets the units used by the presentation (media) timeline. By default, PTS units are

nanoseconds (as if this were called with numerator of 1e9 and denominator of 1).

This ratio must lie between 1/60 (1 tick per minute) and 1e9/1 (1ns per tick).

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

Sets the maximum threshold (in seconds) between explicit user-provided PTS

and expected PTS (determined using interpolation). Beyond this threshold,

a stream is no longer considered 'continuous' by the renderer.

Defaults to an interval of half a PTS 'tick', using the currently-defined PTS units.

Most users should not need to change this value from its default.

Example:

A user is playing back 48KHz audio from a container, which also contains

video and needs to be synchronized with the audio. The timestamps are

provided explicitly per packet by the container, and expressed in mSec

units. This means that a single tick of the media timeline (1 mSec)

represents exactly 48 frames of audio. The application in this scenario

delivers packets of audio to the AudioRenderer, each with exactly 470

frames of audio, and each with an explicit timestamp set to the best

possible representation of the presentation time (given this media

clock's resolution). So, starting from zero, the timestamps would be..

[ 0, 10, 20, 29, 39, 49, 59, 69, 78, 88, ... ]

In this example, attempting to use the presentation time to compute the

starting frame number of the audio in the packet would be wrong the

majority of the time. The first timestamp is correct (by definition), but

it will be 24 packets before the timestamps and frame numbers come back

into alignment (the 24th packet would start with the 11280th audio frame

and have a PTS of exactly 235).

One way to fix this situation is to set the PTS continuity threshold

(henceforth, CT) for the stream to be equal to 1/2 of the time taken by

the number of frames contained within a single tick of the media clock,

rounded up. In this scenario, that would be 24.0 frames of audio, or 500

uSec. Any packets whose expected PTS was within +/-CT frames of the

explicitly provided PTS would be considered to be a continuation of the

previous frame of audio. For this example, calling 'SetPtsContinuityThreshold(0.0005)'

would work well.

Other possible uses:

Users who are scheduling audio explicitly, relative to a clock which has

not been configured as the reference clock, can use this value to control

the maximum acceptable synchronization error before a discontinuity is

introduced. E.g., if a user is scheduling audio based on a recovered

common media clock, and has not published that clock as the reference

clock, and they set the CT to 20mSec, then up to 20mSec of drift error

can accumulate before the AudioRenderer deliberately inserts a

presentation discontinuity to account for the error.

Users whose need to deal with a container where their timestamps may be

even less correct than +/- 1/2 of a PTS tick may set this value to

something larger. This should be the maximum level of inaccuracy present

in the container timestamps, if known. Failing that, it could be set to

the maximum tolerable level of drift error before absolute timestamps are

explicitly obeyed. Finally, a user could set this number to a very large

value (86400.0 seconds, for example) to effectively cause *all*

timestamps to be ignored after the first, thus treating all audio as

continuous with previously delivered packets. Conversely, users who wish

to *always* explicitly schedule their audio packets exactly may specify

a CT of 0.

Note: explicitly specifying high-frequency PTS units reduces the default

continuity threshold accordingly. Internally, this threshold is stored as an

integer of 1/8192 subframes. The default threshold is computed as follows:

RoundUp((AudioFPS/PTSTicksPerSec) * 4096) / (AudioFPS * 8192)

For this reason, specifying PTS units with a frequency greater than 8192x

the frame rate (or NOT calling SetPtsUnits, which accepts the default PTS

unit of 1 nanosec) will result in a default continuity threshold of zero.

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

Sets the reference clock that controls this renderer's playback rate. If the input

parameter is a valid zx::clock, it must have READ, DUPLICATE, TRANSFER rights and

refer to a clock that is both MONOTONIC and CONTINUOUS. If instead an invalid clock

is passed (such as the uninitialized `zx::clock()`), this indicates that the stream

will use a 'flexible' clock generated by AudioCore that tracks the audio device.

`SetReferenceClock` cannot be called once `SetPcmStreamType` is called. It also

cannot be called a second time (even if the renderer format has not yet been set).

If a client wants a reference clock that is initially `CLOCK_MONOTONIC` but may

diverge at some later time, they should create a clone of the monotonic clock, set

this as the stream's reference clock, then rate-adjust it subsequently as needed.

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

Sets the usage of the render stream. This method may not be called after

`SetPcmStreamType` is called. The default usage is `MEDIA`.

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

Sets the usage of the render stream. This method may not be called after

`SetPcmStreamType` is called. The default usage is `MEDIA`.

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

Sets the type of the stream to be delivered by the client. Using this method implies

that the stream encoding is `AUDIO_ENCODING_LPCM`.

This must be called before `Play` or `PlayNoReply`. After a call to `SetPcmStreamType`,

the client must then send an `AddPayloadBuffer` request, then the various `StreamSink`

methods such as `SendPacket`/`SendPacketNoReply`.

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

Enables or disables notifications about changes to the minimum clock lead

time (in nanoseconds) for this AudioRenderer. Calling this method with

'enabled' set to true will trigger an immediate `OnMinLeadTimeChanged`

event with the current minimum lead time for the AudioRenderer. If the

value changes, an `OnMinLeadTimeChanged` event will be raised with the

new value. This behavior will continue until the user calls

`EnableMinLeadTimeEvents(false)`.

The minimum clock lead time is the amount of time ahead of the reference

clock's understanding of "now" that packets needs to arrive (relative to

the playback clock transformation) in order for the mixer to be able to

mix packet. For example...

+ Let the PTS of packet X be P(X)

+ Let the function which transforms PTS -> RefClock be R(p) (this

function is determined by the call to Play(...)

+ Let the minimum lead time be MLT

If R(P(X))

<

RefClock.Now() + MLT

Then the packet is late, and some (or all) of the packet's payload will

need to be skipped in order to present the packet at the scheduled time.

The value `min_lead_time_nsec = 0` is a special value which indicates

that the AudioRenderer is not yet routed to an output device. If `Play`

is called before the AudioRenderer is routed, any played packets will be

dropped. Clients should wait until `min_lead_time_nsec > 0` before

calling `Play`.

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

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

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