Community-Tests messen konstant 140-200ms End-to-End-Latenz bei Standard-Bass-Shaker-Software im Sim Racing, über verschiedene Soundkarten und Hardware-Setups hinweg. Diese Seite erklärt jede verantwortliche Schicht, mit belegten Zahlen wo verfügbar und einer klaren Kennzeichnung, wo nicht.
Haptisches Feedback ist eine Kette vom Spielereignis bis zur physischen Shaker-Bewegung. Bei Standard-Haptik-Software dominieren drei Schichten die Gesamtverzögerung. Keine einzelne Schicht ist für sich allein katastrophal. Das Problem ist, dass sie sich stapeln.
Die 140-200ms stammen aus Community-Messungen über 7+ Soundkarten-Setups. Die Einzelwerte pro Schicht basieren auf dokumentierten oder aus öffentlichen technischen Quellen berechneten Angaben. Wo Werte geschätzt oder theoretisch abgeleitet sind, wird das im Text vermerkt.
Gemessene Gesamtlatenz: 140-200ms.[1]
Bevor Audio erzeugt wird, muss die Bass Shaker-Software wissen, dass im Sim etwas passiert ist. Die meiste Bass Shaker-Software verwendet ein Polling-Modell: Sie prüft in festem Takt auf neue Daten, verarbeitet Effekte und gibt Audio aus.
Die Eigenschafts-Aktualisierungsrate von Standard-Bass-Shaker-Software läuft mit bis zu 60Hz.[2] Bei 60Hz wird alle 16,7ms geprüft. Ein Ereignis, das direkt nach einer Abfrage eintritt, wartet die vollen 16,7ms bis zur nächsten, bevor haptische Ausgabe ausgelöst wird. Im Durchschnitt kommen so ~8ms Wartezeit hinzu.
Das ist unabhängig von der Telemetrierate des Spiels selbst. iRacing schreibt mit 360Hz Sub-Samples in den Shared Memory (ein Bereich im RAM deines PCs, in dem das Spiel Live-Telemetrie veröffentlicht). ACC und AC schreiben einen Snapshot pro gerendertem Frame, typischerweise 60-240Hz je nach FPS. In beiden Fällen ist der Flaschenhals die Software, die liest, nicht der Sim, der schreibt.
Track Impulse liest iRacings Shared Memory über ein ereignisgesteuertes Modell. Es gibt keine Polling-Schleife. Die Engine wird im selben Moment aktiv, in dem neue Telemetrie geschrieben wird, typischerweise innerhalb von 1ms nach dem Physik-Tick des Spiels.
Bevor Ton deine Lautsprecher oder Shaker erreicht, durchläuft er eine Audio-Engine: Software, die Audio mixt, puffert und verarbeitet. Standard-Bass-Shaker-Software nutzt eine allgemeine Audio-Engine, die für Spiel-Soundtracks und filmische Effekte entwickelt wurde. Diese Engines priorisieren Stabilität über Geschwindigkeit und verwenden große interne Puffer, um Audio-Aussetzer zu vermeiden.
Crash-Logs von Standard-Bass-Shaker-Software zeigen Audio-Initialisierungsaufrufe, die auf FMOD hindeuten, eine weit verbreitete Audio-Engine.[3] FMODs offizielle API-Dokumentation gibt an, dass die Standard-Puffereinstellungen Audio durch 4 Blöcke von jeweils ~21ms leiten. So sieht das in Zahlen aus:
// 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
FMODs Dokumentation bestätigt die Latenzformel als (numbuffers - 1.5) x blocksize, was bei Standardeinstellungen ungefähr 53ms durchschnittliche Mixer-Latenz ergibt, bevor irgendein OS-Audio-Overhead anfällt.[3]
Wir können die genaue Konfiguration keiner Drittanbieter-Haptik-Software bestätigen. Puffergröße und Blockanzahl können von den FMOD-Standardwerten abweichen. Die Zahlen oben veranschaulichen die Kategorie des Problems, nicht zwingend den exakten Beitrag in einem bestimmten Produkt. Die 140-200ms Gesamtlatenz sind Community-Messwerte, nicht aus diesen Schichtwerten berechnet.
WASAPI (Windows Audio Session API) ist die Schnittstelle, über die die meisten Windows-Anwendungen Audio an deine Soundkarte senden. Im Shared Mode, dem Standard der meisten Anwendungen, leitet Windows Audio aus verschiedenen Apps durch einen zentralen Mixer, bevor es deine Hardware erreicht. Dieser Mischprozess fügt Verzögerung hinzu, die du nicht durch Puffereinstellungen entfernen kannst.
Unabhängige Tests mit FlexASIO zeigen konstant, dass WASAPI Shared Mode eine Latenz von mehr als 20ms unabhängig von der Puffergröße erzeugt.[4] Das ist eine von Windows auferlegte Untergrenze, kein konfigurierbarer Parameter.
Microsoft hat in Windows 10/11 eine Low-Latency-Audio-Option eingeführt, die dies theoretisch auf 1,3ms reduzieren kann. Allerdings müssen sowohl die Anwendung als auch dein Soundkartentreiber dies explizit unterstützen. Standard-Bass-Shaker-Software nutzt es nicht.[5]
ASIO (Audio Stream Input/Output) wurde von Steinberg speziell entwickelt, um das Windows- Audio-Latenzproblem für Echtzeit-Musikproduktion zu lösen. Der entscheidende architektonische Unterschied: ASIO umgeht den Windows Audio-Mixer vollständig und kommuniziert direkt mit dem Treiber deiner Soundkarte.
Bei 64 Samples / 48kHz (eine typische ASIO-Einstellung) beträgt die Audio-Ausgabelatenz 64 / 48000 x 1000 = 1,33ms. Das ist der Wert, den Track Impulse mit einem 64-Sample ASIO-Puffer erreicht.
Track Impulse adressiert jede Schicht des Stacks direkt:
Statt auf einem Timer nach neuen Daten zu suchen, hört Track Impulse direkt zu: Das Spiel teilt der Engine im selben Moment mit, dass neue Telemetrie bereitsteht. Keine Polling-Verzögerung. iRacing liefert 360Hz Sub-Samples (mehrere Physik-Snapshots pro Frame) über diese Methode. ACC und AC liefern einen Render-Frame-Snapshot, die Telemetriefrische skaliert also mit deinen FPS.
Vier unabhängige Effekt-Engines (eine pro Fahrzeugecke) verarbeiten Dämpfergeschwindigkeit, Vibrationsfrequenz, Raddrehzahl und RPM gleichzeitig. Wenn der Sim mehrere Physik-Updates in einen einzigen Frame packt, werden alle der Reihe nach verarbeitet. <1ms Verarbeitungszeit.
Die Ausgabe über ASIO umgeht den Windows Audio-Stack vollständig. 1,3ms Audio-Ausgabelatenz. Keine allgemeine Audio-Middleware, kein WASAPI Shared-Mode-Overhead, kein OS-Mixing.
Funktioniert mit jedem ASIO-fähigen Audio-Interface. LF, RF, LR, RR unabhängig zugeordnet. ~1ms Hardware-Overhead. Gesamt: ab 2ms End-to-End.
Die Gesamtlatenz hängt von der Telemetrierate und der Frame-Struktur des Sims ab. ASIO-Ausgabe und Hardware-Overhead (~2,3ms zusammen) sind bei allen Sims konstant. Die Variable ist das Telemetriealter.
iRacings 360Hz Sub-Sample-Modell bedeutet, dass die neuesten Daten in einem Frame bei Commit nur 2,78ms alt sind. Die ältesten sind 16,67ms alt. Mit ~1,3ms ASIO-Ausgabe und ~1ms Hardware-Overhead ergibt sich eine Spanne von 5-19ms. ACC und AC verwenden einen Render-Frame-Snapshot: Das Spiel schreibt ein Telemetrie-Update pro gerendertem Frame. Bei 144 FPS beträgt das Frame-Intervall 6,9ms, mit ~2,3ms Stack-Overhead also ein Bereich von 2-9ms. Höhere FPS liefern frischere Telemetrie. Bei 60 FPS weitet sich der Bereich auf ~2-19ms.
Installiere Track Impulse, die Low-Latency Bass Shaker-Software, die diese Lücke schließt, neben deinem bestehenden Haptik-Setup und vergleiche direkt. Kostenlos während der Beta. Keine Kreditkarte erforderlich. Einrichtung in unter 10 Minuten.