template <typename BuilderImpl>class WireTableBaseBuilder
Defined at line 6294 of file fidling/gen/sdk/fidl/fuchsia.hardware.audio/fuchsia.hardware.audio/cpp/fidl/fuchsia.hardware.audio/cpp/wire_types.h
Public Methods
::fuchsia_hardware_audio::wire::RingBufferProperties Build ()Build and return the table. The builder should not be used after this.
bool has_needs_cache_flush_or_invalidate ()void clear_needs_cache_flush_or_invalidate ()Clears the needs_cache_flush_or_invalidate field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
bool & needs_cache_flush_or_invalidate ()When set to true, indicates that the ring buffer runs in a different cache coherency domain,
and thus clients must ensure that their data writes are flushed all the way to main memory
(during playback), or that their view of the ring buffer must be invalidated before any
reads (during capture). This is because there may be hardware external to the CPUs that
reads/writes main memory, bypassing the CPUs.
When set to false, indicates that the ring buffer runs in the same cache coherency domain as
the CPUs, hence the driver is not required to flush/invalidate the ring buffer.
Note that in this case, the driver and client still must synchronize their data access, for
instance by inserting the appropriate acquire fences before reading and releasing fences
after writing, or (more commonly) by obeying the Producer/Consumer pattern described in
[Ring Buffer Behavior](https://fuchsia.dev/fuchsia-src/development/audio/ring_buffer.md).
Required.
BuilderImpl & needs_cache_flush_or_invalidate (bool elem)When set to true, indicates that the ring buffer runs in a different cache coherency domain,
and thus clients must ensure that their data writes are flushed all the way to main memory
(during playback), or that their view of the ring buffer must be invalidated before any
reads (during capture). This is because there may be hardware external to the CPUs that
reads/writes main memory, bypassing the CPUs.
When set to false, indicates that the ring buffer runs in the same cache coherency domain as
the CPUs, hence the driver is not required to flush/invalidate the ring buffer.
Note that in this case, the driver and client still must synchronize their data access, for
instance by inserting the appropriate acquire fences before reading and releasing fences
after writing, or (more commonly) by obeying the Producer/Consumer pattern described in
[Ring Buffer Behavior](https://fuchsia.dev/fuchsia-src/development/audio/ring_buffer.md).
Required.
bool has_turn_on_delay ()void clear_turn_on_delay ()Clears the turn_on_delay field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
int64_t & turn_on_delay ()The driver's best estimate of the time needed for the hardware to emit (during playback) or
accept (during capture) frames, after a channel is activated by `SetActiveChannels`.
The driver estimates that after `SetActiveChannels(channel)->(set_time)` enables a channel,
its data will resume flowing at approximately `set_time` + `turn_on_delay`.
Hardware can take time to become fully operational (e.g. due to a power state change, or
communication delays between a Bluetooth driver's multiple hardware entities). The client
must take this delay into account, if it is unacceptable to drop the actual audio frames
and instead play/capture silence during this interval.
If not included, `turn_on_delay` is unknown.
Optional.
BuilderImpl & turn_on_delay (Wrapper_Ignore_Me_< ::fidl::ObjectView<int64_t>> elem)The driver's best estimate of the time needed for the hardware to emit (during playback) or
accept (during capture) frames, after a channel is activated by `SetActiveChannels`.
The driver estimates that after `SetActiveChannels(channel)->(set_time)` enables a channel,
its data will resume flowing at approximately `set_time` + `turn_on_delay`.
Hardware can take time to become fully operational (e.g. due to a power state change, or
communication delays between a Bluetooth driver's multiple hardware entities). The client
must take this delay into account, if it is unacceptable to drop the actual audio frames
and instead play/capture silence during this interval.
If not included, `turn_on_delay` is unknown.
Optional.
bool has_driver_transfer_bytes ()void clear_driver_transfer_bytes ()Clears the driver_transfer_bytes field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
uint32_t & driver_transfer_bytes ()Size (in bytes) of the temporary buffers or FIFOs used by the driver when consuming or
generating the ring buffer contents.
The `driver_transfer_bytes` field is covered extensively in
[Ring Buffer Behavior](https://fuchsia.dev/fuchsia-src/development/audio/ring_buffer.md).
`driver_transfer_bytes` must not include the impact of delays caused by hardware or software
processing abstracted by the driver. Those delays are communicated by `internal_delay` and
`external_delay` fields in `DelayInfo`; they are orthogonal to this value.
Required.
BuilderImpl & driver_transfer_bytes (uint32_t elem)Size (in bytes) of the temporary buffers or FIFOs used by the driver when consuming or
generating the ring buffer contents.
The `driver_transfer_bytes` field is covered extensively in
[Ring Buffer Behavior](https://fuchsia.dev/fuchsia-src/development/audio/ring_buffer.md).
`driver_transfer_bytes` must not include the impact of delays caused by hardware or software
processing abstracted by the driver. Those delays are communicated by `internal_delay` and
`external_delay` fields in `DelayInfo`; they are orthogonal to this value.
Required.
Protected Methods
void WireTableBaseBuilder< ::fuchsia_hardware_audio::wire::RingBufferProperties, BuilderImpl> (::fidl::ObjectView< ::fidl::WireTableFrame< ::fuchsia_hardware_audio::wire::RingBufferProperties>> && frame)