When playing sound using the Atom library, latency from the playback request until the sound is output can be minimized if the following conditions are met.
(After executing the criAtomExPlayer_Start function, a play sound request is sent to the platform-specific sound library during the initial server processing.)
On-memory playback
No voice takeover occurs
Fader not used
Output to native sound renderer
If the above conditions 1 through 4 are not met, the following type of latency will be observed.
About Condition 1
For streaming playback, sound playback begins only after loading some data from the file when the criAtomExPlayer_Start function is called.
(Playback will be delayed until the amount of data required for playback to begin is loaded.)
In particular, when seeking in a file for playback, it can result in a long latency time before playback begins because the file header must be read and analyzed, the seek position calculated, and then data loaded from the seek position.
About Condition 2
When voice takeover occurs, the voice currently playing is stopped and the next sound is played, so this increases the latency until the next sound is played.
In particular, if the sound to be stopped is streaming, there will be a delay until the file is completely loaded, which can result in long latency times.
About Condition 3
When using the fader, the fade-in and fade-out sounds must be synchronized internally in the Atom library, which requires the equivalent of 1 V extra time for processing until the sound can be played.
About Condition 4
When outputting to the native sound renderer, the playback request is issued at the same time as when the decoded PCM data is passed to the platform-specific sound library.
When ASR is used, the decoded result is mixed in software and added to the currently playing sound buffer.
(Newly written data is played back only after all data written to the sound buffer at that time has been played.)
Therefore, this results in latency that is as long as the length of the current sound buffer.
Attention
ASR must be used for WASAPI output via the Atom library.
(WASAPI does not support functions like sampling rate conversion or mixing, so this processing must be handled by ASR.)
How to Reduce Sound Playback Latency
In order to reduce the latency until a sound is played, conditions 1 through 4 above must be adhered to as closely as possible.
The following are some other methods to help reduce sound playback latency.
Reduce the sound buffer size. (*This is effective only when using ASR.)
The sound buffer size can be changed via API calls when using the PC version of the Atom library.
(The settings are adjusted based on the worst-performing hardware, so the default sized buffer is 4 V.)
Attention
If the size of the mixing buffer is too small, sound break will occur.
Appropriate buffer size depends on the hardware used, so when adjusting these parameters on an application designed for a general-purpose PC, we recommend giving the user the ability to customize these settings themselves in the options for your application.
(For arcade games and other cases when the target hardware is static and known, there is no problem with adjusting these parameters to the optimal settings without the ability for later customization.)
Shortening the Server Processing Interval
The Atom library wakes up a thread and performs processing based on the server processing interval specified at initialization.
Therefore, the latency experienced until a sound is played will be shorter when this server processing interval is shorter, even if the above conditions 1 through 4 are exactly the same.
For example, if server processing is set to occur at 30 Hz, the maximum time required until a sound playback request is handled can be up to 33.3 ms.
If server processing is set to occur at 120 Hz, the request will be received within 8.3 ms when made at exactly the same time.
Attention
However, the server processing interval depends on the timer accuracy and priorities of any other threads operating simultaneously, so there is no guarantee that a sound playback request will be received and handled within the specified server processing interval time.
Furthermore, the latency experienced until sound playback occurs will be decreased by increasing the server processing frequency. But this will in turn increase the overhead that comes along with server processing and thus increase the overall processing load of the Atom library.
Additional Notes
The above explanation includes only latency resulting from within the Atom library.
Apart from the latency discussed above, physical sound playback latency also includes latency resulting from platform-specific sound libraries and playback device latency.
