由于服务器周期和混音缓冲区等各种原因，从发声请求到实际从扬声器输出声音的延迟可能会是一个令人头痛的问题。
当声音的混音缓冲区非常大时或产生多层混音缓存时，会造成最大的影响。
在智能手机或平板电脑等中，由于系统端混音并输出除电话声等个别应用程序之外的声音，
混音缓冲区或会增大或变成多层。

Android

作为Android OS的功能，ADX2支持低延迟播放，但具有同时播放数和采样率等限制。

预设延迟

ADX2的预设设置具有足够余量（＝延迟）以防止声音中断。如果目标规格清晰，则可以调整混音缓冲区容量。

服务器周期

ADX2周期性地执行解码、调整流缓冲区、声音参数更新处理。
如果该周期为60fps，则以16msec间隔执行处理，因此最小也会发生16.666msec的处理延迟。
执行处理的线程也很重要，通过比应用程序高的线程执行管理。
除游戏处理之外，还必须考虑声音的处理周期。
如果这些设置不完整，将会发生如声音中断、噪声、短循环及发声时机摇摆等各种问题。

与其他中间件的冲突

在ADX2中，利用服务器周期中的空闲时间执行解码等处理。
如果后台有极端阻止的处理运行，则可能无法按照预期播放声音。
很难不同时运行文件系统等锁定硬件资源的处理。
另外，CRI的文件系统和视频播放（Sofdec）的设计是不会阻止ADX2的运行动作的

解码延迟

按照解码等处理的最小单位（128sample等）集中执行。
基本上无法执行比该单位更精细的控制。

混音延迟

即使在混音多个声音的解码结果的情况下，也按照60~130msec单位集中执行。
如果终端性能高，可以进一步减少混音延迟，但混音延迟短时则容易变得不稳定。

中间件外的混音延迟

有时在终端Level和OS Level执行与Android和iPhone等其他应用程序的混音。
这些通常都设置得较大，就会出现延迟问题。
Android的低延迟播放仍然会存在这些延迟，因此会发生100msec级别的延迟。
顺便说一下，由于iOS是10msec级别，因此比较容易创建乐器应用和声音游戏，
但Android可能需要在考虑延迟的情况下重新考虑游戏设计。
而这些信息也会因终端和OS而异。

Windows

wasapi的低延迟播放

有时中间件外的混音延迟也可能会很大。通过在PC中使用wasapi，可以大幅减少延迟。

详情请参照每个机型的SDK文档。

应用程序延迟

按按钮时或连续按下时的延迟

播放作为按钮音的声音时，如果是OS等准备的按钮，由于防止再入处理正在运行，
会出现第一次反应好但第二次以后变差等情况。
另外，有些终端从液晶触摸处理到传递给应用程序也可能存在延迟。