SHAPE Overview

A key component of the Xbox One audio system is the Scalable Hardware Audio Processing Engine (SHAPE). The purpose of the SHAPE hardware is to efficiently perform very commonly use audio functions through the use of fixed-function hardware blocks, and to provide a programmable embedded Audio Control Processor (ACP) to control those blocks. There are four main fixed-function blocks: XMA, Sample Rate Convertor (SRC), Equalizer and Compression, and Filter Volume.

To enable high speed operation and minimize traffic on the main memory bus, there is a Direct Memory Access (DMA) process for accessing system memory, and special internal memory called mix buffers. A mix buffer is a block of memory that stores one full audio frame of data. SHAPE hardware typically reads from one or two mix buffers, and writes to an output mix buffer. There are a few exceptions to this general process, such as XMA decoding, and the DMA and SRC blocks.

Many titles will not implement flowgraphs directly; XAudio2, and audio middleware implement SHAPE components implicitly. However, constructing flowgraphs provides the greatest flexibility and access to the audio-acceleration capabilities of the Xbox One console.

This section provides an overview of the SHAPE hardware and the function blocks.

Control Flow

A typical control flow for processing audio follows:

  1. A compressed XMA audio data file is loaded into main system memory.
  2. The XMA decoder block decodes a portion of the XMA data into PCM data, storing the output in an XMA Decode buffer in system memory.
  3. The Sample Rate Convertor (SRC) block reads the PCM samples from the XMA Decode buffer and performs the necessary sample rate conversion and pitch shifting. This allows audio data of an arbitrary sampling rate to be brought into the SHAPE accelerator blocks. The SRC block outputs audio data running at the fixed rate of 48000Hz to an internal mix buffer.
  4. Any additional SHAPE processing is now performed, reading and writing to temporary mix buffers. The processing performed is controlled by the Audio Control Processor, which itself is driven by the application through the ACP API described in this documentation set. These processes include equalizing, compression, filter scaling and volume scaling.
  5. The final stage is called Speaker Output Accumulation, where speaker mix buffers collect and mix the samples from multiple sound sources for playback. Optional global audio effects can be processed at this stage.

There is an alternative process flow that enables more arbitrary processing performed by the main application CPU. The first three steps are identical to those just described.

  1. A compressed XMA audio data file is loaded into main system memory.
  2. The XMA decoder block decodes a portion of the XMA data into PCM data, storing the output in an XMA Decode buffer in system memory.
  3. The Sample Rate Convertor (SRC) block reads the PCM samples from the XMA Decode buffer and performs the necessary sample rate conversion and pitch shifting. This allows audio data of an arbitrary sampling rate to be brought into the SHAPE accelerator blocks. The SRC block outputs audio data running at the fixed rate of 48000Hz to an internal mix buffer.
  4. At this step the process flow diverges, using the DMA system one or more mix buffers are transferred to the main system memory.
  5. The application CPU performs any signal processing required on the buffer in main memory.
  6. Using the DMA system, the processed audio data is transferred from the main memory buffer into a temporary mix buffer. After this step the process is identical to that described above.
  7. Any additional SHAPE processing is now performed, reading and writing to temporary mix buffers. The processing performed is controlled by the Audio Control Processor, which itself is driven by the application through the ACP API described in this documentation. These processes include equalizing, compression, filter scaling and volume scaling.
  8. The final stage is called Speaker Output Accumulation, where speaker mix buffers collect and mix the samples from multiple sound sources for playback. Optional global audio effects can be processed at this stage.

The individual SHAPE blocks are controlled by two main software elements, contexts and the execution list. The contexts, which are stored in main memory, keep the state and provide control for the processing elements within the specific SHAPE hardware blocks. They are initially generated by the CPU and can be updated by either the CPU or the SHAPE Audio Control Processor. The contexts are read into the SHAPE subsystem with each audio frame, as needed by the individual hardware blocks. With an audio frame size of 128 samples and a sampling rate of 48kHz, contexts are swapped at a rate of 375Hz per audio channel.

The execution list is a list of meta commands that are processed by the SHAPE audio processor. Since the SHAPE audio processor is programmable and flexible, the format and function of the execution list is flexible. Some of the meta commands have implicit data, while others have explicit arguments. The meta commands also specify where the specific SHAPE hardware blocks get their input and write their output through the use of the mix buffers. The mix buffers are allocated by the hardware.

The list of commands sent to the SHAPE hardware for processing is referred to as a flowgraph. Flowgraphs are discussed in detail in the ACP Overview.

Figure 1.  The four SHAPE accelerator blocks and their interaction with the other major components.

DMA

The Direct Memory Access (DMA) system supports read and write functionality with automatic float to integer and integer to float conversion. The DMA system utilizes circular buffers containing de-interleaved samples in 128 sample blocks.

The DMA processor allows the SHAPE engine to send data from mix buffers up to main system memory and retrieve data from main system into the mix buffers for further processing. DMA is done on a block basis, transferring one audio frame of data at a time. In order to facilitate block-interleaved data, a skip value specifies the number of audio frame blocks in system memory to skip (from the base address) when reading or writing samples. Multichannel streams therefore require one DMA context per channel.

Audio data samples are always read and written as 32-bit values, either integer or float, as specified in the DMA context FloatConvert flag. Note that the direction of the DMA (read or write) is specified in the DMA command, not in the DMA context. This helps reduce the amount of data bandwidth. The DMA engine has no signal processing, but can perform float to integer conversion (or integer to float). This allows the application CPU to process data samples in floating point format.

To calculate the size of a DMA buffer, use the following formula.

fullBufferSizeInBytes = 128 * 4 * numChannels * numFrames

The read and write pointers are incremented as follows.

readPointer = (readPointer + 1) % numFrames  

writePointer = (writePointer + 1) % numFrames

Addresses within the audio buffer are calculated as follows.

readAddress = audioBuffer + (128 * 4 * ((readPointer * numChannels) + channel))  

writeAddress = audioBuffer + (128 * 4 * ((writePointer * numChannels) + channel))

If for example a DMA buffer contains three frames and four channels, the buffer will be organized as follows, with each channel block containing 128 contiguous samples.

Figure 2.  A DMA buffer.

There are latency considerations as the SHAPE clock is independent of the CPU clock. Hardware to software, or software to hardware, transitions incur a 2.66 ms latency. In synchronization critical code, and using multiple transitions for some of those sounds, consider implementing a CPU clock based delay to synchronize the sound rendering. Consider also developing latency-tolerant sub-mixes to reduce the CPU use.

XMA

The XMA format supports mono, stereo, and interleaved multichannel sound, with variable bit rates and compression. Several improvements have been made over the Xbox 360 implementation of XMA, including a higher clock rate (40% improvement in pitch shifting capabilities, for example) and increased voice count (from 320 to 512).

The XMA decoder block decodes a portion of the XMA data in main memory and returns the PCM data to an XMA decode buffer in main memory. The XMA decoder block is identical to the Xbox 360 XMA decoder except for some minor state enhancements for interfacing with other SHAPE components.

The XMA decoder register block is augmented with state information relating to the decoded output for each voice. Five bits per XMA context specify how much audio data remains unconsumed in the PCM output buffer. These registers are implemented inside the XMA decoder block, so that they are always available to determine if there are enough samples to lock the context for the SRC without reading main memory.

Note xWMA is not supported by SHAPE, but is supported through the use of XAudio2.

PCM

Linear Pulse Code Modulation (PCM) supports up to 7.1 surround sound at 48KHz. The ACP will downmix if the user’s sound system is, for example, 5.1 or stereo. S/PDIF output will be supported.

Linear or circular PCM buffers are supported, containing 16 bit mono or stereo integer content, 32 bit mono float or 32 mono integer (24 bits left justified, or 32 bits with the lower 8 bits masked off).

Sample Rate Convertor

The Sample Rate Convertor (SRC) block reads 16, 24 or 32-bit fixed-point, or 32-bit floating-point PCM data from system memory and performs integer-based sample rate conversion. The output data is written to mix buffers. For input data, the SRC block can either take the output of the XMA hardware decoder or data that is maintained by software. The SRC block has tight integration with the XMA decoder. This allows the SRC block to determine if there are enough samples of decoded PCM data in the XMA decode buffer to create and complete an audio frame of samples without reading main memory.

An SRC process is typically used for musical instrument emulation, conversion of input samples to an octave lower or higher than the source, or effects such as the Doppler Effect.

The SRC operates in either mono or stereo mode. The PCM data is read from memory and converted to a common 24-bit fixed-point format for sample rate conversion. The output is written to either one or two mix buffers depending on the mode. Stereo data is stored in memory as an interleaved stream of 16-bit data with the left channel in the least significant 16 bits of each 32-bit word and the right channel in the most significant 16 bits. In stereo mode, the PCM data is read and simultaneously de-interleaved. The left channel data (sample 0,2,4,6…) is processed and output to one mix buffer and the right channel data (sample 1,3,5,7…) is written to a second mix buffer.

Figure 3.  Sample rate conversion modes.

Although input to the SRC block may be at any sampling rate up to 384 kHz minus epsilon, the output data will be a constant 48kHz. Epsilon is the small delta between requested integer values and the floating point values that the hardware actually uses.

SHAPE can process up to 512 channels (any mix of mono and stereo) of SRC per audio frame.

The SRC supports both linear and polyphase interpolation, mono and stereo, and a resampling range from 1:16 (four octaves down) to 3.99:1 (nearly two octaves up).

Equalization and Compression

The function of the compressor is to limit the amount of dynamic range in the signal. It does this by monitoring the level of input and creating a dynamic gain value. The gain value is then used as a multiplier of the signal, scaling it appropriately, depending on the current level of the input signal. In other words, it is an automatic volume control, which constantly monitors the input signal and is constantly adjusting itself.

The compressor will only act on signals above a specific threshold. If the signal is less than the threshold, the signal will pass through unaltered. Threshold is set by the application as part of the EQComp context data. There is programmable control in the context to perform compression or expansion.

The compressor alters the sound data according to a ratio parameter. This specifies how much attenuation should be done on the incoming signal in the event it exceeds the threshold. The ratio is exactly that: the ratio of incoming level to outgoing level. At a ratio of 2:1, every 2dB of level over the threshold will result in 1dB output from the compressor over the threshold level. With a ratio of 1:1, the compressor is essentially off. Ratio is set by the application as part of the context data. The diagram below shows the effect a compressor has on an input signal. Below the threshold, the output is equal to the input. Above the threshold, the output is reduced in relation to the input by an amount specified by the ratio (approximately 2:1 in the example here).

Figure 4.  The input/output volume curve.

Two additional parameters specify how quickly the compressor should activate, that is how long it should take until the compressor fully attenuates sounds over the threshold by the amount specified by ratio. These parameters are attack and release. Attack and release are specified in milliseconds, and correspond to how quickly the compressor should vary the output gain in response to the signal exceeding or falling below the threshold. These adjustments can be linear or log based. The diagram below shows how the desired output level is not achieved until the input has exceeded the threshold for the time specified by attack, and similarly returns to unity only after the input is under the threshold for the time specified by release.

Figure 5.  The attack/release timing.

The input is then multiplied by the current output gain. That first multiply performs the actual compression, namely scaling the signal through a time-varying function based on the input amplitude. There is one additional gain scaling, which is the final step. This is called the “makeup gain” and is an unchanging value set by the application. Because the result of the compression, particularly at low thresholds, can result in a relatively low-gain signal, the makeup gain is used to bring the signal back into usable range.

One additional parameter in the Compressor is RMS. In normal mode the input level is instantaneous, calculated every sample. In RMS mode, a running average, representing an approximation of the RMS value, is kept over the previous 128 samples. The running average is used as the input level, rather than the absolute level of the current input sample.

The EQ/Compressor-Expander block contains two separate processing units in series: a three-band programmable equalizer and a dynamic range compressor. It is used to control the frequency and dynamic range for sounds. It takes its input from one or two mix buffers. One input is the audio signal to be processed. Optionally, the second input is the control signal used to determine the audio compression, this is called the sidechain input.

The equalizer has fully programmable coefficients. This enables full software control over the transfer function of the equalizer.

Figure 6.  The equalizer is implemented as three serial biquad filters, designated as A, B and C.

Each of the biquad filters implements the following equation, where x is the input, y the output, and a1, a2, b0, b1 and b2 are the coefficients. The coefficients can be accessed in a SHAPE_EQCOMP_CONTEXT structure.

        y[n] = (b0/a0)*x[n] + (b1/a0)*x[n-1] + (b2/a0)*x[n-2] - (a1/a0)*y[n-1] - (a2/a0)*y[n-2]

When performing equalization on a sound, typically certain frequency areas are either cut or boosted. In the case of cutting (attenuating) frequencies, there is no problem; the output signal will be at an equal or lower level than the input. However, when frequencies are boosted, there is typically a corresponding increase in the peak-to-peak dynamic range of the signal; “boosting the lows” by 6dB will result in output gain higher than in the input. If the input signal were already full scale (-0dBFS), the output necessarily will exceed the maximum.

For this reason, the dynamic range within the three cascaded Biquad EQ sections maintains an additional 8 bits of precision to the left of the binary point—s.23 input format becomes s8.23 during EQ processing. The additional range allows each EQ stage to provide gain boost without saturating the audio output in most instances. However, under maximum input conditions, with maximum gain of +18dB applied over all three stages it will be possible to saturate the third stage, in which case the hardware detects this peak overflow event.

The filter coefficients of each Biquad (b0, b1, b2, a1, a2) are 24-bit integers. This allows for a coefficient range of up to +/- 7.998, which is suitable to provide coefficients for the types of filters allowed and a frequency range of 20Hz to 18kHz, and gain range of -18dB to 18dB.

The Compressor-Expander can be operated in one of three sidechain modes.

In Normal mode, there is a single audio input from a mix buffer. The input is fed through the equalizer, where it is subsequently processed by the compressor and output to a mix buffer.

Figure 7.  Normal mode.

In Internal mode, the input signal is fed directly into the audio input of the compressor. The input signal is split and also sent to the equalizer. From the equalizer, it is sent to the sidechain input of the compressor.

Figure 8.  Internal mode.

In External mode, two separate input signals are used, from two separate mix buffers. The input signal is fed through the equalizer and into the audio input of the compression block. The sidechain input signal is fed directly into the sidechain input of the compressor.

Figure 9.  External mode.

SHAPE can process up to 512 EQCOMP contexts per audio frame.

Filter Volume

The Filter/Volume (FLTVOL) block is used to model the occlusion of sounds (sound going around or through an object) and to distribute sound energy to multiple speakers to model the direction in which sound arrives. The Filter/Volume block takes a single channel of input data from a mix buffer, filters and volume scales it and writes the output to a mix buffer. Typically, several Filter/Volume controls are used to generate a one-in, multi-out pan such as a surround sound pan. The panner is typically used for taking a sound and performing an N-speaker pan, plus one or more reverb effects. The addition of the State Variable filter enables a title to easily create enhanced distance effects as well as I3DL2 style occlusion and obstruction effects.

The state variable filter, by its nature, can create resonances causing intermediate values to exceed 1.0 (or -1.0). To mitigate the issues created by intermediate value saturation, the FLTVOL block has a programmable amount of headroom scaling which is applied to the incoming signal and then compensated for upon output. Scaling is achieved by arithmetically right-shifting the data by a certain number of bits. The headroom field of the context specifies the number of bits of right shift the incoming signal will receive prior to FLTVOL processing (0, 1, 2 or 3). Therefore, by specifying a headroom value of 3, the state variable filter can maintain an extra 3 bits (18dB) of headroom for internally created resonances and overflow.

Of course, shifting the incoming data to the right will necessarily reduce precision at the low end; the bottom headroom bits of the incoming audio signal are lost forever. Therefore, the headroom bits should generally be specified as non-zero only if it is determined that internal saturation has occurred in the state variable filter. This can be done by checking the value of the Internal Overflow bit in the FLTVOL context. For the case where the original source data is 16-bits (such as if the original source data is XMA), the headroom bits can usually be set to their maximum (3) without a noticeable change in sound, since the lower order bits are zero padded anyway.

The flexible state variable filter implementation also allows for resonant filtering to be applied to a voice to aid in the creation of interesting audio effects and creating variation. The filter parameters and volume attributes are gradually adjusted on a per sample basis to provide a smooth transition between entry and exit set points. The FLTVOL block is implemented as a Chamberlin filter. The filter provides three modes, High-pass, Low-pass and Band-pass with a variable “Q” (bandwidth) control. The parameters for the Chamberlin filter are calculated as follows.

f := 2*Sin( ( PI * FC )/FS)  

q := 1/Q, where Q ranges from .5 to 5.

The f and q parameters are calculated by software outside of the SHAPE block. When a coefficient is updated, it is ramped to the new value over the course of one audio frame. Control bits are used to determine which output (band reject, high-pass, band-pass or low-pass) is used as the final output of the FLTVOL block.

The context data for each channel or stream is stored in system memory. Though performance is limited to 2560 48kHz simultaneous streams (meaning SHAPE can process up to 2560 FLTVOL contexts per audio frame), the number of contexts addressable in memory is larger to simplify stream reuse scenarios.

The filtering behavior is designed to be identical to that in XAudio2.

Mix Buffers

Mix buffers serve three main purposes.

The SHAPE system makes extensive use of mix buffers, there can be up to 8192 concurrent virtual mix buffers (with IDs from 0 to 8191) rendering to 128 physical channels. Mixing can be done using hardware accumulators so not requiring Direct Memory Access (DMA) to and from memory. Mix buffers support metering and clipping.

Overflow, Magnitude and Saturation

In a title audio engine, managing headroom can be very difficult. For this reason, each SHAPE block maintains state associated with signal overhead and gain. Each block (except the SRC blocks) maintains whether internal saturation has occurred during processing.

In addition to the internal saturation flag, each hardware block also maintains two 4-bit numbers representing the magnitude of the output of the hardware block. The magnitude is calculated by determining the peak output during the audio frame, and counting the leading zeros of the absolute value of the peak. One 4-bit number is maintained with the persistent peak magnitude, the other is reset by the hardware each audio frame.

In addition to monitoring the peak magnitude of each individual hardware block, the peak magnitude of the mix buffers is also maintained. As the output of a hardware block is added to a mix buffer, the peak magnitude is calculated in the same manner (counting leading zeros). Each hardware block state maintains an additional pair of 4-bit peak magnitude values. These values represent the peak magnitude of the mix buffer after the output of the hardware block has been accumulated into the mix buffer. One 4-bit number represents the ongoing, persistent peak magnitude; the other is updated every audio frame. The peak magnitude values are saved in the context of the SHAPE blocks, even though it is the mix buffer state which is actually being represented.

Peak magnitude is encoded according to the following table (coded in the ShapeHardwareContexts.h file).

Binary Value Description
B’0000 Saturation: a value from a calculation to produce an output has overflowed the signed 24-bit range and was replaced with the nearest extreme. Specifically, a value greater than 8,388,607 (0x7F_FFFF) was replaced with 8,388,607 or a value less than -8,388,608 (0x80_0000) was replaced with -8,388,608.
B’0001 Absolute value of the peak was greater than MAX » 1 (0x3F_FFFF).
B’0010 Absolute value of the peak was greater than MAX » 2 (0x1F_FFFF).
B’0011 Absolute value of the peak was greater than MAX » 3.
B’0100 Absolute value of the peak was greater than MAX » 4.
B’0101 Absolute value of the peak was greater than MAX » 5.
B’0110 to B’1101 Similar to the above descriptions, absolute value of the peak was greater than MAX » 6 to 13.
B’1110 Absolute value of the peak was greater than MAX » 14.
B’1111 Absolute value of the peak was less than or equal to MAX » 14.

To help manage overhead and avoid overflow and saturation, in addition to fine grain gain settings, a 0 to 7 bit right shift may be performed on the output of a hardware block prior to accumulation into the output mix buffer. This is designated in the context of each SHAPE hardware block.

SHAPE Queues

There are two queues managed by the SHAPE audio processor that help reduce system and app hardware interlocks. The first queue is the Command and Control Queue (CCQ). This queue is used to give the SHAPE audio processor a series of commands to execute whenever it has a chance (usually at the end of processing the current audio frame). Whereas the SHAPE Execution List will be read once for every audio frame output, the CCQ will be read and executed only once. The CCQ is the mechanism for having the CPU update any block context data on an audio frame boundary without requiring a hardware interlock with the SHAPE hardware. Examples of this include supplying more bit stream data for the XMA block, updating context parameters for various blocks, and pointing to a new execution list (which is usually done when changing the audio processing flowgraph).

The second queue is the Status and Reporting Queue (SRQ). This queue is used by the SHAPE audio processor to report various events to the CPU that do not require real time response. Examples include updating bit stream buffer consumption, errors, warnings and flags, debug data, performance data, and status information.

Programming Considerations

Programming directly to the SHAPE hardware is enabled through the IACPHAL interface. However, the process of preparing audio data for the SHAPE hardware is complex so a large number of utility methods, structures and enumerations are provided. These utilities provide most or all of the methods needed to control the SHAPE hardware. Source code for these utilities is included as part of the XDK for the rare cases where the code will need to be amended to handle certain kinds of data.

The only header file that needs to be explicitly included in your project is acphal.h, which references all the utility header files. All the utility functions reference the macro NO_SHAPE_CONTEXT_VALIDATION. If this macro is defined all validation will be omitted, which should be useful for final retail builds.

Refer to the Remarks for the XAudio2Create method for details on sharing SHAPE/XMA resources with instances of XAudio2.

For more details of all the utility methods, refer to the ACP Overview.

Persistent and non-persistent flowgraphs

You can submit flowgraphs to be processed as persistent or non-persistent. Persistent flowgraphs process and then remain resident to repeat their processing in the next frame after read and write pointers have advanced and after other context information is updated. You can use persistent flowgraphs for either of the following scenarios:

Use non-persistent flowgraphs for any of the following scenarios:

Debugging Issues

When developing flowgraphs, registering for messages will help debug any issues that might occur. Specifically, use the NumMessages parameter of Connect. The messaging system provides rich feedback on a variety of issues, including invalid flowgraphs (ACP_FLOWGRAPH_TERMINATED_REASON_INVALID_GRAPH), blocked commands, and frameouts that are caused when you attempt to perform more processing than the hardware frame size of 2.667 msec allows. Before shipping a title, verify consistently successful flowgraph processing by witnessing ACP_MESSAGE_TYPE_FLOWGRAPH_COMPLETED messages for each submitted flowgraph.

Missed messages

If you use ACP messages to drive engine state, and if you handle a large number of messages, then during development you should examine the droppedMessageCount field of ACP_MESSAGE. A non-zero value indicates that the message queue was full and messages had to be dropped. If this value occurs, consider servicing the queue faster and also making the queue larger.

Frame outs

There are a number of reasons a flowgraph might not complete before the end of an audio frame (2.667 msec) is encountered, including processing too many flowgraphs, or the processing of a badly structured flowgraph. This incomplete flowgraph will result in an ACP_FLOWGRAPH_TERMINATED_TIME_EXCEEDED message for persistent flowgraphs, and these persistent flowgraphs will be incomplete. By contrast, a non-persistent flowgraph is not constrained in this manner, and the flowgraph will run until completed, even across frames.

Blocked commands

SRC and DMA commands can report as blocked (ACP_MESSAGE_TYPE_SRC_BLOCKED, ACP_MESSAGE_TYPE_DMA_BLOCKED) in several scenarios:

Command type Blocking scenario
XMA SRC The associated XMA context has a parser error or no source data. The error is SHAPE_XMA_ERROR_STATUS_READ_BUFFER_INVALID_VALIDBUFFER_CURRBUF_IS_0 | SHAPE_XMA_ERROR_STATUS_FRAME_CROSSES_BOUNDARY_INTO_INVALID_READ_BUFFER_VALIDBUFFER_CURRBUF_IS_0 | SHAPE_XMA_ERROR_STATUS_FRAME_CROSSES_BOTH_READ_BUFFER_BOUNDARIES.XMA SRC will not block based on a lack of decoded data.
PCM SRC Associated PCM context is SHAPE_PCM_MODE_CIRCULAR and there is no source data.
Read (DMA from mixbuffer) DMA buffer is full.
Write (DMA to mixbuffer) DMA buffer is empty.

After commands are determined to be blocked (which occurs both before being added to a SHAPE queue for processing and at run-time), commands are removed from the graph, which can lead to dropped audio. During development, you should use blocked commands as the first place to look for flowgraph-handling improvements, and before shipping, your title should prevent commands from being blocked at all.

You can prevent blocked DMA commands by ensuring that your audio buffer is sufficiently large and that data is streamed at regular intervals (related to the buffer size). For example, if you are streaming four hardware frames at a time, ensure some multiple of those frames (at least double-buffered at eight) are in the buffer so the hardware can write ahead of the title’s read pointer. Alternatively, you could enforce emptying of the buffer before submitting the next flowgraph (consume, update DMA read pointer, and then submit the flowgraph).

SRC commands have three modes:

If the last packet of a voice is not submitted with STOP_END (or STOP_IMMEDIATE), then the SRC command will not complete, causing the active flowgraph to stall. A persistent flowgraph will terminate at the end of the audio frame, and a non-persistent flowgraph will never complete.

Synchronization issues

A number of synchronization issues can arise if you do not respect the SHAPE hardware’s consumption practices for contexts and commands. While your titles retain full access to ACP-allocated memory, take care not to modify a context structure while it is in use. You can submit commands (using SubmitCommand) to occur at a specific frame, at the beginning of the next frame, or as soon as possible.

For the last scenario be aware that “as soon as possible” is still asynchronous from any title CPU processing. Some commands may not complete immediately (for exmaple, if a context is in the middle of a non-interruptible operation). Wait for an ACP_MESSAGE_TYPE_COMMAND_COMPLETED to verify that a command has been truly processed.

Refer to the white paper: