If a threading or gameplay latency is 13 ms (a feasible number), and we use the same buffer size of 2048 samples at 48 kHz, and if the command just missed the start of the current buffer being rendered, there will be a worst-case accumulated latency of 56 ms. In addition to this inherent latency with an audio renderer due to the render buffer size, audio commands issued from the game thread take time to get to the audio engine due to game-thread and audio-thread ticks, and general thread communication overhead.
This means that for a buffer that contains 2048 samples rendered at 48k samples per second (kHz), the buffer would result in an audible latency of up to 43 milliseconds (ms). For example, if you were to trigger an explosion VFX and an explosion sound on the same game-thread tick, the latency between seeing the VFX explosion and hearing the sound is determined by this buffer size. This rate also describes the perceived audible latency of any issued commands. A command, for example, might be to play a new sound, stop an old one, or change the parameter of a sound like volume or pitch.īecause of this, the size of the rendered audio buffer directly controls the rate at which new commands are consumed.
It is important to understand that audio engine rendering commands are typically consumed at the beginning of an audio buffer render. These buffers typically contain hundreds or even thousands of samples at a time. A number of reasons make this the only feasible way to render audio in real time on a CPU - CPU cache coherency, hardware API overhead, and so on. In an audio engine, for CPU performance reasons, audio samples are rendered in buffers, and submitted individually to output hardware - a digital audio converter (DAC).
Issues with Accurate Timing and Latency in Audio Rendering
0 kommentar(er)
