コミュニティによるテストでは、複数のサウンドカードとハードウェア構成において、標準的なシムレーシング用バスシェイカーソフトウェアから一貫して140～200msのエンドツーエンド遅延が計測されています。このページでは、遅延の原因となるすべてのレイヤーを、可能な限りソース付きの数値とともに解説します。推定値や原理から導出した数値については、その旨を明記しています。
ハプティクスフィードバックは、ゲーム内イベントからシェイカーの物理的な振動までの一連のチェーンです。標準的なハプティクスソフトウェアでは、3つのレイヤーが合計遅延の大部分を占めています。単独では壊滅的なレイヤーはありませんが、問題はこれらが積み重なることです。
140～200msという数値は、7種類以上のサウンドカード構成でのコミュニティ計測に基づいています。以下のレイヤー別数値は、公開されている技術文書から文書化または算出されたものです。推定値や原理から導出された数値については、本文中にその旨を記載しています。
合計計測値: 140～200ms。[1]
オーディオが合成される前に、バスシェイカーソフトウェアはシム内で何かが起きたことを知る必要があります。ほとんどのバスシェイカーソフトウェアはポーリングモデルを使用しています。固定タイマーで新しいデータをチェックし、エフェクトを処理し、オーディオ出力を書き込みます。
標準的なバスシェイカーソフトウェアのプロパティリフレッシュレートは最大60Hzで動作します。[2] 60Hzでは、1回のチェックが16.7msごとに発生します。チェックが完了した直後に到着したイベントは、ハプティクス出力がトリガーされるまで次のチェックまで16.7ms待つことになります。平均すると、約8msの待機時間が追加されます。
これはゲーム自体のテレメトリレートとは別の問題です。iRacingはサブサンプルを通じて360Hzで共有メモリ（ゲームがライブテレメトリを公開するPCのRAM領域）に書き込みます。ACCとACはレンダリングされたフレームごとに1回スナップショットを書き込み、FPSに応じて通常60～240Hzになります。いずれにしても、ボトルネックはシムがデータを生成することではなく、バスシェイカーソフトウェアがそれを読み取ることにあります。
Track Impulseはイベント駆動型モデルを使用してiRacingの共有メモリを読み取ります。ポーリングループはありません。新しいテレメトリが書き込まれた瞬間にエンジンが起動し、通常はゲームの物理演算ティックから1ms以内です。
音声がスピーカーやシェイカーに到達する前に、オーディオエンジン（オーディオのミキシング、バッファリング、処理を行うソフトウェア）を通過します。標準的なバスシェイカーソフトウェアは、ゲームサウンドトラックや映画的オーディオ向けに設計された汎用オーディオエンジンを使用しています。これらのエンジンは速度よりも安定性を優先し、オーディオの途切れを防ぐために大きな内部バッファを使用します。
標準的なバスシェイカーソフトウェアのクラッシュログからは、広く使用されているオーディオエンジンであるFMODと一致するオーディオ初期化呼び出しが確認されています。[3] FMODの公式APIドキュメントによると、デフォルトの内部バッファ設定では、オーディオは各約21msの4ブロックを通じてキューされます。数値で見ると以下のようになります。
// FMOD System::setDSPBufferSize defaults bufferlength = 1024 // samples per block numbuffers = 4 // blocks in the ring buffer samplerate = 48000 // Hz block_ms = 1024 / 48000 * 1000 // = 21.33ms per block avg_latency = (4 - 1.5) * 21.33 // = ~53ms average latency
FMODのドキュメントでは、レイテンシ計算式を (numbuffers - 1.5) x blocksize と確認しており、デフォルト設定でOSオーディオのオーバーヘッドが適用される前に、平均ミキサーレイテンシは約53msになります。[3]
サードパーティ製ハプティクスアプリケーションが使用する正確な設定は確認できません。バッファサイズとブロック数はFMODのデフォルトと異なる可能性があります。上記の数値は問題のカテゴリを示すものであり、特定の製品における正確な寄与度を示すものではありません。140～200msの合計値はコミュニティ計測に基づくものであり、これらのレイヤー数値から算出されたものではありません。
WASAPI (Windows Audio Session API) は、ほとんどのWindowsアプリケーションがサウンドカードにオーディオを送信する方法です。ほとんどのアプリケーションが使用するデフォルトの共有モードでは、Windowsは複数のアプリからのオーディオを中央ミキサーを通じてルーティングし、ハードウェアに到達する前にミックスします。このミキシング処理により、バッファ設定を変更しても除去できない遅延が発生します。
FlexASIOを使用した独立テストでは、WASAPI共有モードがバッファサイズに関係なく20ms以上のレイテンシを生成することが一貫して示されています。[4] これはWindows自体が課す下限であり、調整可能なパラメータではありません。
MicrosoftはWindows 10/11で低遅延オーディオオプションを追加し、理論的には1.3msまで低減できます。しかし、アプリケーションとサウンドカードドライバーの両方が具体的にサポートする必要があります。標準的なバスシェイカーソフトウェアはこれを使用していません。[5]
ASIO (Audio Stream Input/Output) は、リアルタイム音楽制作におけるWindowsオーディオレイテンシの問題を解決するためにSteinbergが開発しました。そのアーキテクチャ上の最大の特徴は、Windowsオーディオミキサーを完全にバイパスし、サウンドカードのドライバーと直接通信することです。
64サンプル / 48kHz（一般的なASIO設定）では、オーディオ出力レイテンシは 64 / 48000 x 1000 = 1.33msです。これがTrack Impulseが64サンプルのASIOバッファで達成できる数値です。
Track Impulseはスタックの各レイヤーに直接対処しています。
タイマーで新しいデータをチェックする代わりに、Track Impulseは直接リッスンします。新しいテレメトリの準備が整った瞬間にゲームがエンジンに通知します。ポーリング遅延なし。iRacingはこの方式で360Hzサブサンプル（各フレームにパックされた複数の物理演算スナップショット）を配信します。ACCとACはレンダーフレームスナップショットを配信するため、テレメトリの鮮度はFPSに比例します。
4つの独立したエフェクトエンジン（車の各コーナーに1つずつ）がショック速度、ランブルピッチ、ホイールスピード、RPMを同時に処理します。シムが1フレームに複数の物理演算更新をパックする場合、すべてが順番に処理されます。処理時間は1ms未満。
ASIOによる出力はWindowsオーディオスタックを完全にバイパスします。オーディオ出力レイテンシ1.3ms。汎用オーディオミドルウェアなし、WASAPI共有モードのオーバーヘッドなし、OSミキシングなし。
ASIO対応のオーディオインターフェースであれば使用可能です。LF、RF、LR、RRを独立してマッピング。ハードウェアオーバーヘッドは約1ms。合計: エンドツーエンドで最低2ms。
合計レイテンシはシムのテレメトリレートとフレーム構造に依存します。ASIO出力とハードウェアオーバーヘッド（合計約2.3ms）はすべてのシムで一定です。変動するのはテレメトリの経過時間です。
iRacingの360Hzサブサンプルモデルでは、任意のフレームにおける最新データはコミット時点でわずか2.78msの経過時間です。最古のデータは16.67msです。ASIO出力約1.3msとハードウェアオーバーヘッド約1msを加えると、全体の範囲は5～19msになります。ACCとACはレンダーフレームスナップショットを使用します。ゲームが画面に描画するフレームごとに1回テレメトリを更新します。144 FPSではフレーム間隔は6.9msのため、スタックオーバーヘッド約2.3msを加えると範囲は2～9msになります。FPSが高いほどテレメトリは新鮮になり、60 FPSでは範囲が約2～19msに広がります。
Track Impulseは、この遅延を根本から解消するために構築された低遅延バスシェイカーソフトウェアです。既存のハプティクスセットアップと並行してインストールし、直接比較できます。ベータ期間中は無料。クレジットカード不要。10分以内にセットアップ完了。