How Haptic Latency Works

The Latency Stack.
Why Bass Shaker
Software Is Slow.

Community testing consistently measures 140–200ms of end-to-end latency from standard sim racing bass shaker software, across multiple sound cards and hardware setups. This page works through every layer responsible — with sourced figures where available, and clearly flagged where not.

Explained Audio architecture 12 min read
In this guide

Every Step
Adds Latency.

Haptic feedback is a chain from game event to physical shaker movement. In standard haptic software, three layers dominate the total delay. No single layer is catastrophic alone — the problem is that they stack.

Scope & accuracy

The 140–200ms figure comes from community measurement across 7+ sound card setups. Layer-by-layer figures below are documented or calculated from public technical sources. Where figures are estimates or derived from first principles, this is noted inline.

Sim Engine (iRacing, ACC, AC)
Game calculates physics → makes data available
~0ms
↓ telemetry polling loop
Bass Shaker Software Telemetry Loop
Software checks for new data up to 60 times per second
0 – 16.7ms
↓ processes effects → sends to audio engine
General-Purpose Audio Engine
Audio is queued in large internal buffers before output
~50ms avg
↓ Windows audio mixer
Windows WASAPI Shared Mode
OS mixes audio from all applications before hardware output
>20ms floor
↓ sound card → amp → shakers
Audio Interface → Amplifier → Shakers
Hardware conversion — negligible in context
~1–3ms

Total measured: 140-200ms.[1]

16.7ms Per Tick.
Every Tick.

Before any audio is synthesised, the bass shaker software needs to know something happened in the sim. Most bass shaker software uses a polling model — it checks for new data on a fixed timer, processes effects, and writes audio output.

Standard bass shaker software's property refresh rate runs at up to 60Hz.[2] At 60Hz, one check fires every 16.7ms. An event that arrives immediately after a check has just fired will wait the full 16.7ms for the next one before triggering any haptic output. On average, this adds ~8ms of waiting time.

This is distinct from the game's own telemetry rate. iRacing writes to shared memory (a region of your PC's RAM where the game publishes live telemetry) at 360Hz via sub-samples. ACC and AC write a snapshot once per rendered frame — typically 60–240Hz depending on your FPS. Either way, the bottleneck is the bass shaker software reading it — not the sim producing it.

Track Impulse comparison

Track Impulse reads iRacing's shared memory using an event-driven model. There is no polling loop. The engine wakes the moment new telemetry is written which is typically within 1ms of the game's physics tick.

Large Buffers,
By Design.

Before sound reaches your speakers or shakers, it passes through an audio engine — software that mixes, buffers, and processes audio. Standard bass shaker software uses a general-purpose audio engine designed for game soundtracks and cinematic audio. These engines prioritise stability over speed and use large internal buffers to prevent audio dropouts.

Crash logs from standard bass shaker software show audio initialisation calls consistent with FMOD, a widely used audio engine.[3] FMOD's official API documentation states that its default internal buffer settings queue audio through 4 blocks of ~21ms each. Here's what that looks like in numbers:

FMOD latency formula — from official FMOD API documentation
// FMOD System::setDSPBufferSize — default values
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's documentation confirms the latency formula as (numbuffers − 1.5) × blocksize, yielding approximately 53ms average mixer latency at defaults — before any OS audio overhead is applied.[3]

Caveat

We cannot confirm the exact configuration used by any third-party haptic application — buffer size and block count may differ from FMOD defaults. The figures above illustrate the category of problem, not necessarily the precise contribution in any specific product. The 140–200ms total is community-measured, not calculated from these layer figures.

The OS Mixer
Always Costs Something.

WASAPI (Windows Audio Session API) is how most Windows applications send audio to your sound card. In shared mode — the default used by most applications — Windows routes audio from multiple apps through a central mixer before anything reaches your hardware. This mixing step adds delay that you can't remove by changing buffer settings.

Independent testing using FlexASIO consistently shows that WASAPI shared mode produces latency of greater than 20ms regardless of buffer size.[4] This is a floor imposed by Windows itself — not a tunable parameter.

Can't Windows fix this?

Microsoft added a low-latency audio option in Windows 10 that can theoretically reduce this to as low as 1.3ms. However, both the application and your sound card driver have to specifically support it. Standard bass shaker software doesn't use it.[5]

Direct to Hardware.
No OS Mixer.

ASIO (Audio Stream Input/Output) was developed by Steinberg specifically to solve the Windows audio latency problem for real-time music production. Its key architectural difference: it bypasses the Windows audio mixer entirely and talks directly to your sound card's driver.

Property
WASAPI Shared
WASAPI Exclusive
ASIO (native driver)
Min practical latency
>20ms floor
~4–10ms
~1.3ms
Windows OS mixing
Yes — all apps mixed
No
No — direct to hardware
Callback model
OS-managed
OS-managed
Direct from hardware

At 64 samples / 48kHz — a typical ASIO setting — audio output latency is 64 / 48000 × 1000 = 1.33ms. This is the figure Track Impulse operates at with a compatible ASIO interface.

Built to Minimise
Every Layer.

Track Impulse addresses each layer of the stack directly:

1

Sim Telemetry — Event-Driven

Instead of checking for new data on a timer, Track Impulse listens directly — the game tells the engine the moment new telemetry is ready. No polling delay. iRacing delivers 360Hz sub-samples (multiple physics snapshots packed into each frame) via this method. ACC and AC deliver a render-frame snapshot — telemetry freshness scales with your FPS.

2

Effect Engine

Four independent effect engines — one per corner of the car — process shock velocity, rumble pitch, wheel speed, and RPM simultaneously. Where the sim packs multiple physics updates into a single frame, all of them are processed in sequence. <1ms processing time.

3

ASIO Audio Output

Output via ASIO bypasses the Windows audio stack entirely. 1.3ms audio output latency. No general-purpose audio middleware, no WASAPI shared-mode overhead, no OS mixing.

4

Audio Interface → Amplifier → Shakers

Works with any ASIO-capable audio interface. LF, RF, LR, RR independently mapped. ~1ms hardware overhead. Total: as low as 2ms end-to-end.

End-to-end latency by sim

Total latency depends on the sim's telemetry rate and frame structure. The ASIO output and hardware overhead (~2.3ms combined) is constant across all sims — the variable is telemetry age.

Sim
End-to-end range
Telemetry rate
At 200 km/h
iRacing
5–19ms
360Hz sub-sample
Under 1 metre
ACC
2–9ms
Render-frame snapshot
Under 0.5 metres
AC
2–9ms
Render-frame snapshot
Under 0.5 metres

iRacing's 360Hz sub-sample model means the newest data in any given frame is just 2.78ms old at commit time; the oldest is 16.67ms old. With ~1.3ms ASIO output and ~1ms hardware overhead, the full range is 5–19ms. ACC and AC use a render-frame snapshot — the game writes one telemetry update per frame it draws to your screen. At 144 FPS the frame interval is 6.9ms — with ~2.3ms stack overhead, the range is 2–9ms. Higher FPS delivers fresher telemetry; at 60 FPS the range widens to ~2–19ms.

Sources & Notes
  1. 140–200ms measured across 7 sound cards: SimHub Forum — "Usage of low latency audio driver"
  2. SimHub 60Hz property refresh rate: Overtake.gg — ShakeIt AM profile discussion ("SimHub maximum refresh rate is 60Hz")
  3. FMOD buffer defaults and latency formula: FMOD Engine API — System::setDSPBufferSize documentation. FMOD usage visible in haptic software crash logs ("Disposing FMOD output / Allocating FMOD output").
  4. WASAPI shared-mode >20ms floor regardless of buffer size: FlexASIO GitHub issue #55
  5. Microsoft IAudioClient3 and Windows 10 low-latency WASAPI: Microsoft Learn — Low Latency Audio (Windows drivers)

Download Track Impulse Free

Install it alongside any existing haptic setup and compare directly. Free during beta. No credit card required. Set up in under 10 minutes.