音楽を PCM サンプルにデコードし、走行処理とエフェクトラックを通して Android の音声出力に渡します。システムやイヤホンでも待機、再サンプリング、符号化が行われる場合があります。一つのバッファーの大きさは、指の操作から音が聞こえるまでの総遅延ではありません。

PCM の1フレームには同時刻の全チャンネルのサンプルが含まれ、処理ブロックは複数の音声フレームをまとめたものです。時間への換算にはサンプルレートが必要です。画面のフレームレートや一つの処理ブロックを、そのまま聴覚上の遅延とはみなせません。

リアルタイム操作には有線イヤホンをおすすめします。開発者のテストでは、有線に切り替えることで、Bluetooth 使用時のダイヤル操作や揺れ操作に伴う明らかな音の遅れが解消しました。実際の応答は端末、システム、出力機器によって変わります。

フォアグラウンド出力は端末の最小バッファ要件を下限とし、約 30 ms の要求量を組み合わせて音声の滞留を減らします。走行操作が、その後の音により早く反映されるようにするためです。

再生では最大四つの先読みウィンドウと、必要に応じて使用する上限 16 MiB のデコード再利用キャッシュを使います。重複デコードを減らしながらメモリ使用を制限します。曲全体や同量の音声をイヤホンへ送る待ち行列に積むという意味ではありません。

先読み範囲、デコード結果のキャッシュ、出力機器のバッファーは役割が異なります。これらを区別せず、メモリー容量から実際の出力遅延を直接計算することはできません。

エフェクトチェーンは音声ブロックの境界で更新し、約 20 ms かけて旧チェーンから新チェーンへ移行します。この間は処理負荷が一時的に増える可能性がありますが、それだけでノイズの原因とは断定できません。Android がブロックの一部だけを受け取った場合は、処理済みの残りを送信し、同じデータに再びエフェクトをかけません。

バイパスは聞こえる結果を変えますが、インスタンスは状態を保つために演算を続けます。処理負荷を下げるには、不要なインスタンスを取り除いてください。

パチパチ音が出る場合は、チェーンの出力ピークを確認し、高すぎるエフェクトのゲインを下げてクリッピングを調べます。次に不要なエフェクトを削除し、処理負荷を比較します。音声供給が再生に追いつかないバッファー不足と、過大なピークによるクリッピングは別の問題です。過負荷ランプはピークを示すもので、バッファー不足を確認する表示ではありません。これらは原因を絞る手順であり、確定診断ではありません。

バックグラウンドでは通常の1倍速で PCM をまとめて送信し、ラックの処理は維持します。空のラックでは約 200 ms、エフェクトがある場合は約 600 ms のバッファーを要求しますが、確保済み容量の制約を受けます。

大きめのバックグラウンドバッファは、システムのスケジューリングの揺らぎに余裕を持たせます。ただし処理が継続的に追いつかなければ欠落は起こり得ます。前面に戻ると小さなバッファ設定に戻りますが、すでにキューにある音声は消費される必要があります。

ホイール描画は最新の状態だけを保持し、描画待ちは最大一件にして古い状態の蓄積を減らします。画面更新と音声出力は別経路です。Bluetooth の可聴遅延で画面のコマ落ちを直接説明することはできません。

アプリがバックグラウンドに移る、画面が消える、または対象機能を無効にすると、対応する姿勢センサーの読み取りと監視を停止します。動的反射は光を変え、音は変えません。揺れシミュレーションによる音の変化は独立したスイッチで制御します。

現在公開しているのは、有線と Bluetooth に関する開発者の定性的な観察です。条件を完全に記録した、再現可能な総遅延、処理負荷、消費電力の数値測定はまだ公開していません。

比較には端末モデル、OS、出力機器と接続方法、サンプルレート、エフェクト構成、同一の試聴区間が必要です。要求量やバッファ目標値は実測に代わりません。十個のスロットは構成容量であり、すべての組み合わせの円滑な動作、一定の遅延や省電力率を保証しません。