Number of channels.

Sets which channels are active via a bitmask. The least significant bit corresponds to channel index 0.

The sample format of all samples.

The frame format of all samples.

The frame rate for all samples.

The bits per slot for all channels.

The bits per sample for all samples. Must be smaller than bits per channel for samples to fit.

Justification of the samples within a slot.

Clocking of data samples and frame sync output on either raising or falling sclk. If true then the sclk raises on the raising edge of the data and frame sync, i.e. the data will be sampled on the falling edge of sclk (the middle of the sclk cycle). Hence, if false then data will be sampled on the raising edge of sclk.

Number of sclks between the beginning of a frame sync change and audio samples. For example, for I2S set to 1 and for stereo left justified set to 0.

Number of sclks the frame sync is high within a frame. For example, for I2S with 32 bits slots set to 32, for TDM usually set to 1.

Possible number of channels supported.

Sample formats supported.

Frame formats supported.

Rates supported. Values must be listed in ascending order.

The bits per slot supported. Values must be listed in ascending order.

Bits per sample supported. Values must be listed in ascending order.

Number of channels.

The format of all samples.

Bytes allocated to hold a sample, equal or bigger than the valid sample size in valid_bits_per_sample.

Number of valid bits in a sample, must be equal or smaller than bits in bytes_per_sample. If smaller, bits are left justified, and any additional bits must be ignored by the receiver.

The frame rate for all samples.

The driver's best estimate of the time (in the CLOCK_MONOTONIC timeline) at which the playback/capture pointer reached the position indicated by position. turn_on_delay impact should not be incorporated into 'timestamp'. No delays indicated in DelayInfo should be incorporated.

The playback/capture pointer position (in bytes) in the ring buffer at time timestamp as estimated by the driver.

NONE

No frame format as in samples without a frame sync like PDM.

I2S

Format as specified in the I2S specification (left justified, 2 channels, 32 bits per channel, frame sync stays low for the left channel and high for the right channel, data starts one clock cycle after frame sync changes clocked out at the falling edge of sclk).

STEREO_LEFT

Left justified, 2 channels. Data starts at frame sync changes from low to high clocked out at the falling edge of sclk. The frame sync must stay high for bits_per_channel bits for the first channel and low for bits_per_channel bits for the second channel.

STEREO_RIGHT

Right justified, 2 channels. The frame sync must stay high for bits_per_channel bits for the first channel and low for bits_per_channel bits for the second channel.

TDM1

Left justified, variable number of channels, data starts at frame sync changes from low to high clocked out at the rising edge of sclk. The frame sync must stay high for exactly 1 clock cycle.

TDM2

Left justified, variable number of channels, data starts one clock cycle after the frame sync changes from low to high clocked out at the rising edge of sclk. The frame sync must stay high for exactly 1 clock cycle.

TDM3

Left justified, variable number of channels, data starts two clock cycles after the frame sync changes from low to high clocked out at the rising edge of sclk. The frame sync must stay high for exactly 1 clock cycle.

PDM

Pulse Density Modulation samples.

PCM_SIGNED

Signed integer Linear Pulse Code Modulation samples, at the host endianness.

PCM_UNSIGNED

Unsigned integer Linear Pulse Code Modulation samples, at the host endianness.

PCM_FLOAT

Floating point samples, encoded per the IEEE-754 standard.

STREAM_CONFIG

Device supports the fuchsia.hardware.audio/StreamConfig protocol.

DAI

Device supports the fuchsia.hardware.audio/Dai protocol.

CODEC

Device supports the fuchsia.hardware.audio/Codec protocol.

COMPOSITE

Device supports the fuchsia.hardware.audio/Composite protocol.

INTERNAL_ERROR

The driver encountered an otherwise unspecified error while performing the operation.

NOT_SUPPORTED

The operation is not implemented, supported, or enabled.

INVALID_ARGS

An argument is invalid.

WRONG_TYPE

The subject of the operation is the wrong type to perform the operation.

SHOULD_WAIT

The operation cannot be performed currently but potentially could succeed if the caller waits for a prerequisite to be satisfied.

INVALID_ARGS

The ring buffer setup failed due to an invalid argument, e.g. min_frames is too big.

INTERNAL_ERROR

The ring buffer setup failed due to an internal error.

HARDWIRED

Driver is hardwired (will always be plugged in).

CAN_ASYNC_NOTIFY

Driver is able to asynchronously notify of plug state changes.

PCM_SIGNED

Signed integer Linear Pulse Code Modulation samples, at the host endianness.

PCM_UNSIGNED

Unsigned integer Linear Pulse Code Modulation samples, at the host endianness.

PCM_FLOAT

Floating point samples, encoded per the IEEE-754 standard.

1

Minimum frequency guaranteed to be emitted by (or captured in) this channel, in Hz. If min_frequency is not included, then this channel is assumed to cover the entire low-frequency range of this device.

Optional.

2

Maximum frequency guaranteed to be emitted by (or captured in) this channel, in Hz. If max_frequency is not included, then this channel is assumed to cover the entire high-frequency range of this device.

Optional.

1

Describes attributes for this channel set. The size of this vector defines the number of channels supported by this ChannelSet. Each element of the attributes vector defines attributes of a single channel.

Required.

1

The driver's best estimate of the external delay (in nanoseconds) present in the pipeline for the chosen format. When precisely synchronizing presentation across multiple entities (e.g. devices), the external delay should be taken into account. If not included external_delay is unknown.

Optional.

2

The driver's best estimate of the amount of time (in nanoseconds) it takes the hardware to actually start playback/capture after a Start command is issued. It may take some time for the hardware to get into fully operational mode, for example due a power state change. This delay must be taken into account if not getting the initial audio samples played or captured is not acceptable. If not included turn_on_delay is unknown.

Optional.

3

The driver's best estimate of the amount of time (in nanoseconds) it takes the hardware to actually stop playback/capture after a Stop command is issued. It may take some time for the hardware to get into fully stopped mode, for example due a power state change. This delay must be taken into account if playback/capture of samples after a 'Stop' command is not acceptable. If not included, the turn off delay is unknown.

Optional.

1

Driver type is input (true) or output (false) If not included, then the driver may be used for both input and output.

Optional.

2

UI string for the manufacturer name. If not included, the manufacturer is unspecified. If included, this string must be non-empty.

Optional.

3

UI string for the product name. If not included, the product name is unspecified. If included, this string must be non-empty.

Optional.

4

Unique identifier for the codec. If not included, there is no unique id for the Codec.

Optional.

5

Plug Detect Capabilities.

Required.

2

UI string for the manufacturer name. If not set, the manufacturer is unknown. If included, this string must be non-empty.

Optional.

3

UI string for the product name. If not set, the product name is unknown. If included, this string must be non-empty.

Optional.

4

A unique identifier. If not included, there is no unique id for the Device. unique_id arrays starting with 0x42, 0x54, ... (or BT in ASCII) are reserved for drivers implementing Bluetooth technologies. unique_id arrays starting with 0x55, 0x53, 0x42, ... (or USB in ASCII) are reserved for drivers implementing USB technologies. Note that even though the above values map to readable ASCII characters, array values can span the entire uint8 range (0-255).

Optional.

5

An identifier for the clock domain in which this hardware operates. If two hardware devices have the same clock domain, their clock rates are identical and perfectly synchronized. Although these two clocks have the same rate, the clock positions may be offset from each other by an arbitrary (but fixed) amount. The clock_domain typically comes from a system wide entity, such as a platform bus or global clock tree.

There are two special values:

• CLOCK_DOMAIN_MONOTONIC means the hardware is operating at the same rate as the system montonic clock.

• CLOCK_DOMAIN_EXTERNAL means the hardware is operating at an unknown rate and is not synchronized with any known clock, not even with other clocks in domain CLOCK_DOMAIN_EXTERNAL.

If the domain is not CLOCK_DOMAIN_MONOTONIC, client must use position notification updates to recover the hardware's clock.

Required.

1

Driver type is input (true) or output (false)

Required.

2

UI string for the manufacturer name. If not included, the manufacturer is unspecified. If included, this string must be non-empty.

Optional.

3

UI string for the product name. If not included, the product name is unspecified. If included, this string must be non-empty.

Optional.

4

A unique identifier for the driver. If not included, there is no unique id for the driver.

Optional.

5

An identifier for the clock domain in which this hardware operates. If two hardware devices have the same clock domain, their clock rates are identical and perfectly synchronized. Although these two clocks have the same rate, the clock positions may be offset from each other by an arbitrary (but fixed) amount. The clock_domain typically comes from a system wide entity, such as a platform bus or global clock tree.

There are two special values:

• CLOCK_DOMAIN_MONOTONIC means the hardware is operating at the same rate as the system montonic clock.

• CLOCK_DOMAIN_EXTERNAL means the hardware is operating at an unknown rate and is not synchronized with any known clock, not even with other clocks in domain CLOCK_DOMAIN_EXTERNAL.

If the domain is not CLOCK_DOMAIN_MONOTONIC, client must use position notification updates to recover the hardware's clock.

Required.

1

The driver's best estimate (for the chosen format) of the delay internal to the hardware it abstracts.

"Internal" refers to the hardware between the hardware interconnect (DAI) and the ring buffer (e.g. an SoC audio subsystem), whereas "external" refers to hardware on the far side of any hardware interconnect (DAI) (e.g. hardware codecs).

For a given frame during playback, this is any delay after the driver/HW copies it out of the ring-buffer, before it exits any hardware interconnect. For a given frame during recording, this is any delay after it enters the hardware interconnect, before the driver/HW copies it into the ring-buffer.

internal_delay must be taken into account by the client when determining the requirements for minimum lead time (during playback) and minimum capture delay (during capture).

This delay must not include the inherent delay added by the temporary buffering needed to copy data in and out of the ring buffer, which is contained in RingBufferProperties field driver_transfer_bytes.

Required.

2

The driver's best estimate (for the chosen format) of the delay external to the hardware it abstracts.

"External" refers to hardware on the far side of any hardware interconnect (DAI) (e.g. hardware codecs), whereas "internal" refers to hardware between the hardware interconnect (DAI) and the ring buffer (e.g. an SoC audio subsystem).

external_delay must be taken into account by the client when determining the requirements for minimum lead time (during playback) and minimum capture delay (during capture).

If not included, external_delay is unknown. If unknown, a client may treat it however it chooses (consider it zero or some large number, autodetect it, etc).

Like internal_delay, this delay must not include the inherent delay added by the temporary buffering needed to copy data in and out of the ring buffer, which is contained in RingBufferProperties field driver_transfer_bytes.

Optional.

1

Format supporting non-compressed PCM samples.

Required.

1

Current mute state. If not included, the state is unmuted.

Optional.

2

Current Automatic Gain Control (AGC) state. If not included, AGC is disabled.

Optional.

3

Current gain in decibels.

Required.

1

Driver is currently healthy. No health information is provided if this field is not included. This allows drivers to signal their health state in scenarios where they have not enough capabilities or resources to recover on their own, for instance not able to power down the hardware via a GPIO or control over the power subsystem.

Optional.

1

Vector of possible ChannelSets supported. A ChannelSet specifies a channel configuration (including a channel-count), plus a number of optional attributes. Only one ChannelSet is allowed for each unique channel-count. As a result, no two entries in channel_sets can contain attributes vectors with the same length.

Required.

2

Vector of possible SampleFormats supported.

Required.

3

Vector of possible bytes allocated for each sample. Values must be listed in ascending order. All values listed in valid_bits_per_sample must fit into at least the largest bytes_per_sample value.

Required.

4

Vector of possible number of bits containing valid data, within the sample container defined by bytes_per_sample. Values must be listed in ascending order. All values listed must fit into the largest bytes_per_sample value. The valid data bits must be most-significant (left-justified) within the sample container, and any additional bits will be ignored.

Required.

5

Vector of possible frame rates supported. Values must be listed in ascending order.

Required.

1

Driver is currently plugged in. Required

2

Timestamps the information provided in the rest of the fields of this struct. Required.

1

The driver's best estimate (for the chosen format) of the delay external to the hardware it abstracts. External delay must be taken into account when precisely synchronizing presentation across multiple entities (e.g. devices). If not included external_delay is unknown.

Deprecation

Not needed anymore since the functionality is available via WatchDelayInfo below.

2

Size (in bytes) of the temporary buffer used by the driver when consuming or generating ring buffer contents. Required. The ring buffer contents must be produced and consumed at the rate specified with the CreateRingBuffer command, however some amount of buffering is required when the data is written into and read from the ring buffer. For playback the data is consumed by the driver by reading ahead up to fifo_depth bytes. For capture the data is produced by the driver holding up to fifo_depth bytes at the time before committing it to main system memory. Hence fifo_depth must be taken into account by the client when determining either the minimum lead time requirement (for playback) or the maximum capture delay (for capture).

To convert fifo_depth to the corresponding number of audio frames, use the frame size returned by CreateRingBuffer in the StreamConfig protocol, note that the fifo_depth is not necessarily a multiple size of an audio frame.

The ring buffer data may be directly consumed/generated by hardware, in this case fifo_depth maps directly to the size of a hardware FIFO block, since the hardware FIFO block determines the amount of data read ahead or held back.

The ring buffer data may instead be consumed/generated by audio driver software that is conceptually situated between the ring buffer and the audio hardware. In this case, for playback the fifo_depth read ahead amount is set large enough such that the driver guarantees no undetected underruns, this assuming the client is generating the data as determined by the CreateRingBuffer and Start commands. For capture, the fifo_depth held back amount is set large enough such that the driver guarantees no undetected underruns when generating the data as determined by the CreateRingBuffer and Start commands. The driver must set fifo_depth big enough such that the potential delays added by any software interfacing with the audio hardware do not occur under most scenarios, and must detect and report underruns. How an underrun is reported is not defined in this API.

Deprecation

Not needed anymore since the functionality is available via driver_transfer_bytes below.

3

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.

Required.

4

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.

5

Size (in bytes) of the temporary buffer used by the driver/HW when consuming or generating the ring buffer contents.

The ring buffer contents must be produced and consumed at the rate specified with the CreateRingBuffer command, using data transfers between a temporary buffer and the ring buffer. For playback, audio frames are consumed by the driver in transfers as large as driver_transfer_bytes. For capture, audio frames are produced by the driver in transfers as large as driver_transfer_bytes. In both cases, this many frames must accumulate before they are read from or committed to the ring buffer.

These data transfers mean that there is always a section of the ring buffer that is unsafe for the client to be writing/reading. This unsafe buffer region is defined on one side by the current position 'P', and on the other side by the 'safe pointer' location 'S'. Once the ring buffer starts, these two pointers begin moving. 'P' begins moving from position 0 at the start_time from Start. The region between these pointers must not be read or written by the client at that time. The diagrams below note these pointers as 'P' and 'S'.

During playback, client must write data BEFORE hardware transfers occur. During capture, client can read captured data only AFTER hardware transfers occur. For this reason, during playback 'S' is always ahead of 'P', whereas during capture 'S' is always behind 'P'.

Playback

Before they start the ring buffer, clients may safely write any ring buffer location. It is recommended that they write at least driver_transfer_bytes of initial audio, since they must always stay at least that far ahead of where the driver/HW is reading, and upon Start the hardware might immediately consume that much data from the ring buffer. Otherwise, the client relies on the zeroed-out contents of the VMO to be the initial audio read by the driver/HW.

                                      Ring Buffer
 +-------------------------+-------------------------------------------------------------+
 |<---                                 safe to write                                 --->|
 |             (to pre-populate the ring buffer before starting the hardware)            |
 +-------------------------+-------------------------------------------------------------+
 0=P                       S                                                             0

Once the ring buffer is started, it is not safe for the client to write data to the ring buffer between 'P' and 'S', because this represents data already in use (potentially already consumed). The client may safely write the rest of the ring buffer (between 'S' and '0/P').

                                      Ring Buffer
 +-------------------------+-------------------------------------------------------------+
 |<--- unsafe to write --->|<---                    safe to write                    --->|
 |< driver_transfer_bytes >|           (empty unless prewritten by the client)           |
 +-------------------------+-------------------------------------------------------------+
 0=P                       S                                                             0

As time passes, the driver/HW reads the data in chunks of driver_transfer_bytes or less, at the rate specified in CreateRingBuffer. The Position/Safe pointers move to the right at the same rate, but do so smoothly. As a result, the "unsafe for client writes" area moves gradually through the ring buffer, while maintaining a constant size equal to driver_transfer_bytes. Thus, after some period we now have:

                                      Ring Buffer
 +------------+-------------------------+------------------------------------------------+
 |<-- safe -->|<--- unsafe to write --->|<--               safe to write              -->|
 |  to write  |< driver_transfer_bytes >|       (not yet consumed by the hardware)       |
 +------------+-------------------------+------------------------------------------------+
 0            P                         S                                                0

Later, 'S' wraps around the ring buffer before 'P' does. Note that the region from 0 to 'S', plus the region from 'P' to the end of the ring buffer, adds up to driver_transfer_bytes:

                                      Ring Buffer
 +---------------+------------------------------------------------------------+----------+
 |<--- unsafe -->|<---                   safe to write                    --->|<-unsafe->|
 |< driver_transf|                                                            |er_bytes >|
 +---------------+------------------------------------------------------------+----------+
 0               S                                                            P          0

In steady state, any area outside of the pointers 'P' and 'S' is safe to write:

                                      Ring Buffer
 +--------------------------------+-------------------------+----------------------------+
 [<--       safe to write      -->|<--- unsafe to write --->|<--     safe to write    -->|
 |  (prior data already consumed) |< driver_transfer_bytes >|                            |
 +--------------------------------+-------------------------+----------------------------+
 0                                P                         S                            0

Recording

While recording, it is only safe for the client to read that part of the ring buffer that is not simultaneously being written by the driver/HW. Before capture begins, it may read the entire ring buffer, but the driver has not yet written anything for the client to read. This is the ring buffer at the moment that the client starts the ring buffer:

                                      Ring Buffer
 +---------------------------------------------------------------------------------------+
 [<---                     empty (not yet written by the hardware)                    -->|
 +---------------------------------------------------------------------------------------+
0=S=P                                                                                    0

Once capture begins, the driver/HW acquires frames, eventually making its first data transfer to the ring buffer starting at '0'. These transfers are of unknown size but may be as large as driver_transfer_bytes; they occur at the rate specified in CreateRingBuffer. Before the driver/HW has written at least driver_transfer_bytes into the ring buffer, the client cannot yet safely read any of the newly captured frames:

                                      Ring Buffer
 +--------------+------------------------------------------------------------------------+
 [<-- unsafe -->|<--                           safe to read                           -->|
 |< driver_transfer_bytes >|     (but empty, not yet written by the hardware)            |
 +--------------+------------------------------------------------------------------------+
0=S             P                                                                        0

Once the driver/HW has written at least driver_transfer_bytes of data into the ring buffer, 'S' begins to smoothly move forward at the same rate as 'P' (as determined by the ring buffer's rate and sample format). The client can safely read frames in the region between '0' and 'S'. It is unsafe for the client to read data between 'S' and 'P', because this is where the driver/HW is simultaneously writing. This region gradually progresses across the ring buffer, maintaining a constant size of driver_transfer_bytes. After some time we have:

                                      Ring Buffer
 +----------------+-------------------------+--------------------------------------------+
 [< safe to read >|<---  unsafe to read --->|<--             safe to read             -->|
 | captured audio |< driver_transfer_bytes >|      (not yet written by the hardware)     |
 +----------------+-------------------------+--------------------------------------------+
 0                S                         P                                            0

Later, 'P' wraps around the ring buffer before 'S' does. Note that the region from 0 to 'P', plus the region from 'S' to the end of the ring buffer, adds up to driver_transfer_bytes:

                                      Ring Buffer
 +-----------+------------------------------------------------------------+--------------+
 |<--unsafe->|<---                    safe to read                    --->|<---unsafe--->|
 |< driver_tr|                      (captured audio)                      |ansfer_bytes >|
 +-----------+------------------------------------------------------------+--------------+
 0           P                                                            S              0

In steady state, i.e. once the process has wrapped around the ring buffer, any area outside of pointers 'S' and 'P' is safe to read:

                                      Ring Buffer
 +--------------------------------+-------------------------+----------------------------+
 [<--       safe to read       -->|<---      unsafe     --->|<--     safe to read     -->|
 |                                |< driver_transfer_bytes >|                            |
 +--------------------------------+-------------------------+----------------------------+
 0                                S                         P                            0

Hardware versus software

The ring buffer data may be directly consumed/generated by hardware, i.e. driver_transfer_bytes can be mapped directly to the size of a hardware FIFO block, since a hardware FIFO block determines the upper limit amount of data read ahead or held back. Note that if the FIFO buffer is not used in the traditional "high water" way (such as a "ping pong" design where only half the FIFO size is used at any time -- even during the very first transfers at Start time), then driver_transfer_bytes may be set to a smaller value but must be at least equal to the largest amount of data ever stored in the FIFO buffer. Even if the transfer size never exceeds half the size of the FIFO, if the full size of the FIFO is used (for instance, upon Start when filling an initially empty hardware FIFO), then driver_transfer_bytes must be set to the entire size of the FIFO buffer.

The ring buffer data may instead be consumed/generated by audio driver software that is conceptually situated between the ring buffer and the audio hardware. In this case, for playback, the driver_transfer_bytes read ahead amount must be large enough such that the driver guarantees no undetected underruns, based on the client requirement to generate data based on the CreateRingBuffer rate and the start_time from Start. For capture, driver_transfer_bytes must be large enough for the driver to guarantee no underruns when generating the data as determined by the CreateRingBuffer and Start commands.

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.

1

A unique identifier. If not included, there is no unique id for the StreamConfig. unique_id arrays starting with 0x42, 0x54, ... (or BT in ASCII) are reserved for drivers implementing Bluetooth technologies. unique_id arrays starting with 0x55, 0x53, 0x42, ... (or USB in ASCII) are reserved for drivers implementing USB technologies. Note that even though the above values map to readable ASCII characters, array values can span the entire uint8 range (0-255).

Optional.

2

Driver type is input (true) or output (false)

Required.

3

Gain mute capability. If not included, the StreamConfig can't mute.

Optional.

4

Automatic Gain Control (AGC) capability. If not included, the StreamConfig can't AGC.

Optional.

5

Minimum gain in decibels.

Required.

6

Maximum gain in decibels.

Required.

7

Gain step in decibels, this value must not be negative, but may be zero to convey an effectively continuous range of values. Must not exceed max_gain_db - min_gain_db.

Required.

8

Plug Detect Capabilities.

Required.

9

UI string for the manufacturer name. If not included, the manufacturer is unspecified. If included, this string must be non-empty.

Optional.

10

UI string for the product name. If not included, the product name is unspecified. If included, this string must be non-empty.

Optional.

11

An identifier for the clock domain in which this hardware operates. If two hardware devices have the same clock domain, their clock rates are identical and perfectly synchronized. Although these two clocks have the same rate, the clock positions may be offset from each other by an arbitrary (but fixed) amount. The clock_domain typically comes from a system wide entity, such as a platform bus or global clock tree.

There are two special values:

• CLOCK_DOMAIN_MONOTONIC means the hardware is operating at the same rate as the system montonic clock.

• CLOCK_DOMAIN_EXTERNAL means the hardware is operating at an unknown rate and is not synchronized with any known clock, not even with other clocks in domain CLOCK_DOMAIN_EXTERNAL.

If the domain is not CLOCK_DOMAIN_MONOTONIC, client must use position notification updates to recover the hardware's clock.

Required.

1

Supported formats for non-compressed PCM samples, with attributes.

Required.

1

2

1

2

1

2

1

2

1

2

1

2

1

2

1

The format type of all samples in the DAI, listed in DaiFrameFormatStandard.

2

The format type of all samples in the DAI, specified in DaiFrameFormatCustom.

1

2

1

2

1

2

1

2

1

3