サーバー周期やミキシングバッファなど様々な要因で発音リクエストから実際にスピーカーから波形が出力されるまでのレイテンシーが問題になることがあります。
もっとも大きな影響を受けるのはサウンドのミキシングバッファが非常に大きい場合やミキシングバッファが多段になっている場合に起こります。
スマートフォンやタブレットでは、電話波形などの個々のアプリケーション以外の波形もシステム側でミキシングして出力を行うため、
ミキシングバッファが大きくなったり、多段階層になっていたりします。

Android

ADX ではAndroid OS向けの機能として低遅延再生がサポートされていますが、同時再生数やサンプリングレートなどの制限があります。

デフォルトのレイテンシー

ADX のデフォルト設定は、音途切れが起きないよう余裕のある（＝遅延のある）設定になっています。対象となるスペックがはっきりしている場合はミキシングバッファ容量の調整が可能な場合があります。

サーバー周期

ADX では、デコードやストリーミングバッファの調整、サウンドのパラメーターの更新処理を周期的に行います。
この周期が例えば60fpsの場合、16msec間隔で処理が行われるため、最短でも16.666msecの処理遅延が発生します。
処理を行うスレッドも重要で、アプリケーションよりも高いスレッドで管理が行われます。
ゲームの処理とは別にサウンドの処理周期も検討する必要があります。
これらの設定が不完全な場合、音途切れやノイズ、ショートループや発音タイミングの揺れなど様々な問題が発生します。

他のミドルウェアとの競合

ADX ではサーバー周期の中での空き時間を利用してデコードなどの処理が行われます。
極端にブロックする処理が裏で動いた場合にサウンドの再生が意図通りにならない場合があります。
ファイルシステムなどハードの資源をロックするような処理とは同時に動かさないことが懸命です。
なお、CRIのファイルシステムやムービー再生(Sofdec)は ADX をブロックするような動作をしないよう設計されています

デコードのレイテンシー

デコードなどの処理の最小単位(128sampleなど）まとめて行われます。
この単位より細かい制御は基本的に行えません。

ミキシングのレイテンシー

複数の音のデコード結果をミックスする場合も60~130msec単位でまとめて行われます。
端末性能など高いものであればもっと削ることもできますが、短い場合は不安定になりがちです。

ミドルウェア外でのミキシングによるレイテンシー

AndroidやiPhoneなど他のアプリケーションとのミキシングが端末レベルやOSレベルで行われる場合があります。
これらは通常大きめな設定となっておりレイテンシーの問題にあがります。
Androidの低レイテンシー再生であってもこれらのレイテンシーがあるため、100msecレベルのレイテンシーが発生します。
ちなみにiOSでは10msecレベルであるため楽器アプリや音ゲー作成が比較的容易ですが、
Androidではレイテンシーを考慮したゲームのデザインから考え直す必要がある場合があります。
これらの情報は端末やOSによっても状況が異なります。

Windows

wasapiによる低遅延再生

ミドルウェア外でのミキシングによる遅延も大きな場合があります。PCではwasapiを使うことでレイテンシーを大幅に下げることが可能です。

詳しくは機種別SDKのドキュメントも参照してください。

アプリケーションよりの話

ボタンを押した時、連続で押した時のレイテンシー

ボタンの音としてサウンドを再生する場合、OSなどが用意しているボタンの場合、再突入を防ぐ処理が行われているため、
初回は反応が良いが、2回目以降が悪いなどといったことが考えられます。
また、液晶のタップの処理がアプリケーションへ伝わるまでの遅延がある端末もあります。