CRIWARE Unity Plugin Manual  Last Updated: 2024-07-12
Sound playback latency estimation
Attention
  • This feature is not available when SonicSYNC is enabled
  • We recommend using SonicSYNC for a lower latency.

Sound playback latency estimation

Sound playback latency estimation

In this section, the sound playback latency means the time between when the program triggers a playback and when the sound is actually played on the device speaker.
atom_about_start_latency.png
Definition of sound playback latency
On Android devices, the sound playback latency is generally long and can differ greatly between devices.

Problems caused by sound playback latency

Sound playback latency can cause issues if scenes must be switched based on the music in a rhythm game, for example.
If the sound playback latency is long, the music and scenes will not match synchronously, even if the program switches the scenes based on the timing of the music playback.
Since the sound playback latency can be very different depending on the device, it is difficult to adjust the timing in the program.
Users will sometimes feel uncomfortable with the time lag between their movements, such as tapping and when the corresponding sounds are played.
This problem is also caused by latency, which cannot be solved by latency estimation.
For a solution to this problem in ADX, see " Low-latency sound playback on Android ".

Sound playback latency estimation in ADX

ADX provides the "sound playback latency estimation" feature to simplify the timing adjustments the application must make for each device.
The idea is that if the program could dynamically obtain the sound playback latency of a device, there would be no need to maintain a list of such latencies for each device in the program.
However, the sound playback latency estimation in ADX does not guarantee completely correct results. It may return a result that is very different from the actual latency depending on the device.
Please note that this feature is assumed to be used as a reference only, when the application adjusts its settings for each device.
However, please note that the microphone is not used.

Differences in the results due to the SDK version

Starting with SDK 3.08.00, the values obtained with this function are smaller.
This is linked to SonicSYNC, as well as the updates of partial playback when not using SonicSYNC, and the specifications of the latency estimation function.

Using the sound playback latency estimation

By default, the audio playback latency estimation is disabled.
To be able to use it, it must be configured in Unity Editor and a function call from the script is required. Follow the steps below:
  1. Initialize the CRI Atom library with the CriWare.CriWareInitializer component.
  2. Call the CriWare.CriAtomExLatencyEstimator.InitializeModule function from the script to start the latency estimation processing.
  3. For the latency estimation processing that is asynchronously executed, check the execution status and the latency estimation value by the CriWare.CriAtomExLatencyEstimator.GetCurrentInfo function.
  4. If the status shows "Completed"(Done), record the latency estimation value (msec) in the application code.
  5. Call the CriWare.CriAtomExLatencyEstimator.FinalizeModule function to finalize the latency estimation processing.
It may take a few seconds to complete the latency estimation processing from the start.
For an implementation example of the above procedure, please see [CriAtom] Estimating the latency of sound playback on Android device .

Using the estimation results in the program

Calculating how long a sound had been played

The ADX's playback time acquisition function does not consider latency.
The application must consider latency to calculate the correct time.
When scenes are changed based on music, how long the sound has been played can be calculated as shown below.

atom_howto_use_latency.png
Formula to calculate for how long a sound has been playing (example)
For example, if the latency is 200 ms, the sound is started at -200 ms.
When the playback time is obtained from ADX, subtract the 200 ms from the latency to get the real playing time.
Use this formula as a reference to adjust scene changes in the program.
However, the ADX latency estimation is not perfect. In a music game, it is desirable that the player can fine-tune the timing.
In that case, the latency estimation can be used as the default value for the adjustment when the application is started for the first time.

When should the latency be estimated?

The latency estimation varies somewhat every time the application is started.
So if the latency is estimated each time, the user may end up being confused. It is a good idea to prevent the latency value from being recalculated each time automatically once it has been saved.

When is the latency estimation not working well?

In some cases, the result of the ADX latency estimation may end up being very different from the actual latency.
The following issues are known:
  • When wireless earphones are used, it is likely that latency is longer than the estimation.
  • If the device's sound options provide special sound effects, it is likely that latency is longer than the estimation.
Note that there are no plans to resolve these problems .

Cause of delay estimation failure

The execution status acquired by CriWare.CriAtomExLatencyEstimator.GetCurrentInfo may change to "Error" due to one of the following reasons:
  • Unable to play audio due to OS issues.
  • The delay was too large and the process timed out.
    Please assume that the delay estimation will fail and take measures such as prompt to restart the application, or use the default latency instead.

    If the error "E2015062623:failed to realize OpenSLES player." occurs and the delay estimation fails, the maximum number of OpenSLES players that the OS can generate may have been reached due to the use of low-delay playback.
    Please reduce the capacity of the voice pool for low-latency playback specified in the CRIWARE Library Initializer component and check if it fixes the problem.