Como a Latência Háptica Funciona

A Pilha de Latência.
Por Que o Software de
Bass Shaker é Lento.

Testes da comunidade medem consistentemente 140 a 200ms de latência ponta a ponta em software padrão de bass shaker para sim racing, em diversas placas de som e configurações de hardware. Esta página analisa cada camada responsável, com números documentados quando disponíveis e claramente sinalizados quando não.

Explicado Arquitetura de áudio 12 min de leitura
Neste guia

Cada Etapa
Adiciona Latência.

O feedback háptico é uma cadeia desde o evento do jogo até o movimento físico do shaker. No software háptico padrão, três camadas dominam o atraso total. Nenhuma camada isolada é catastrófica; o problema é que elas se somam.

Escopo e precisão

O valor de 140 a 200ms vem de medições da comunidade em mais de 7 configurações de placas de som. Os valores por camada abaixo são documentados ou calculados a partir de fontes técnicas públicas. Quando os valores são estimativas ou derivados de princípios básicos, isso é indicado no texto.

Motor do Simulador (iRacing, ACC, AC)
Jogo calcula a física e disponibiliza os dados
~0ms
↓ loop de polling de telemetria
Loop de Telemetria do Software de Bass Shaker
Software verifica novos dados até 60 vezes por segundo
0 – 16.7ms
↓ processa efeitos e envia ao motor de áudio
Motor de Áudio de Propósito Geral
Áudio é enfileirado em buffers internos grandes antes da saída
~50ms media
↓ mixer de áudio do Windows
WASAPI Modo Compartilhado do Windows
SÓ mixa áudio de todos os aplicativos antes da saída para o hardware
>20ms piso
↓ placa de som, amplificador e shakers
Interface de Áudio, Amplificador e Shakers
Conversão de hardware: desprezível neste contexto
~1–3ms

Total medido: 140-200ms.[1]

16,7ms Por Tick.
Todo Tick.

Antes de qualquer áudio ser sintetizado, o software de bass shaker precisa saber que algo aconteceu no simulador. A maioria dos softwares de bass shaker usa um modelo de polling: verifica novos dados em um timer fixo, processa os efeitos e gera a saída de áudio.

A taxa de atualização de propriedades do software padrão de bass shaker roda a até 60Hz.[2] A 60Hz, uma verificação ocorre a cada 16,7ms. Um evento que chega imediatamente após uma verificação ter acabado de disparar vai esperar os 16,7ms completos até a próxima antes de acionar qualquer saída háptica. Em media, isso adiciona ~8ms de tempo de espera.

Isso é diferente da própria taxa de telemetria do jogo. O iRacing escreve na memória compartilhada (uma região da RAM do seu PC onde o jogo publica telemetria em tempo real) a 360Hz via sub-amostras. ACC e AC escrevem um snapshot por frame renderizado, tipicamente 60 a 240Hz dependendo do seu FPS. De qualquer forma, o gargalo é o software de bass shaker lendo os dados, não o simulador produzindo.

Comparação com o Track Impulse

O Track Impulse lê a memória compartilhada do iRacing usando um modelo orientado a eventos. Não há loop de polling. O motor acorda no instante em que nova telemetria é escrita, tipicamente em menos de 1ms do tick de física do jogo.

Buffers Grandes,
Por Design.

Antes do som chegar aos seus alto-falantes ou shakers, ele passa por um motor de áudio: software que mixa, armazena em buffer e processa o áudio. Software padrão de bass shaker usa um motor de áudio de propósito geral projetado para trilhas sonoras de jogos e áudio cinemático. Esses motores priorizam estabilidade sobre velocidade e usam buffers internos grandes para evitar falhas de áudio.

Logs de erro de software padrão de bass shaker mostram chamadas de inicialização de áudio consistentes com o FMOD, um motor de áudio amplamente utilizado.[3] A documentação oficial da API do FMOD afirma que suas configurações padrão de buffer interno enfileiram áudio em 4 blocos de ~21ms cada. Veja como isso fica em números:

FMOD latency formula (from official FMOD API documentation)
// 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

A documentação do FMOD confirma a fórmula de latência como (numbuffers - 1.5) x blocksize, resultando em aproximadamente 53ms de latência média do mixer nas configurações padrão, antes de qualquer overhead de áudio do SÓ ser aplicado.[3]

Ressalva

Não podemos confirmar a configuração exata usada por qualquer aplicativo háptico de terceiros; o tamanho do buffer e a contagem de blocos podem diferir dos padrões do FMOD. Os números acima ilustram a categoria do problema, não necessariamente a contribuição precisa em qualquer produto específico. O total de 140 a 200ms é medido pela comunidade, não calculado a partir desses valores por camada.

O Mixer do SÓ
Sempre Custa Algo.

WASAPI (Windows Áudio Session API) é como a maioria dos aplicativos Windows envia áudio para sua placa de som. No modo compartilhado, o padrão usado pela maioria dos aplicativos, o Windows roteia o áudio de múltiplos apps através de um mixer central antes de qualquer coisa chegar ao hardware. Essa etapa de mixagem adiciona atraso que você não consegue remover alterando configurações de buffer.

Testes independentes usando FlexASIO mostram consistentemente que o modo compartilhado do WASAPI produz latência superior a 20ms independentemente do tamanho do buffer.[4] Esse é um piso imposto pelo próprio Windows, não um parâmetro ajustável.

O Windows não pode corrigir isso?

A Microsoft adicionou uma opção de áudio de baixa latência no Windows 10/11 que teoricamente pode reduzir isso para até 1,3ms. No entanto, tanto o aplicativo quanto o driver da sua placa de som precisam ter suporte específico. Software padrão de bass shaker não utiliza isso.[5]

Direto ao Hardware.
Sem Mixer do SÓ.

ASIO (Áudio Stream Input/Output) foi desenvolvido pela Steinberg especificamente para resolver o problema de latência de áudio do Windows para produção musical em tempo real. Sua principal diferença arquitetural: ele ignora completamente o mixer de áudio do Windows e se comunica diretamente com o driver da sua placa de som.

Propriedade
WASAPI Compartilhado
WASAPI Exclusivo
ASIO (driver nativo)
Latência mínima prática
>20ms piso
~4–10ms
~1,3ms
Mixagem do SÓ Windows
Sim, todos os apps mixados
Não
Não, direto ao hardware
Modelo de callback
Gerenciado pelo SÓ
Gerenciado pelo SÓ
Direto do hardware

A 64 amostras / 48kHz (uma configuração típica de ASIO), a latência de saída de áudio é 64 / 48000 x 1000 = 1,33ms. Esse é o valor que o Track Impulse consegue atingir com um buffer ASIO de 64 amostras.

Construído para Minimizar
Cada Camada.

O Track Impulse aborda cada camada da pilha diretamente:

1

Telemetria do Simulador: Orientada a Eventos

Em vez de verificar novos dados por timer, o Track Impulse escuta diretamente: o jogo avisa o motor no instante em que nova telemetria está pronta. Sem atraso de polling. O iRacing entrega sub-amostras a 360Hz (múltiplos snapshots de física empacotados em cada frame) por esse método. ACC e AC entregam um snapshot por frame renderizado, então a frescor da telemetria escala com o seu FPS.

2

Motor de Efeitos

Quatro motores de efeitos independentes (um por canto do carro) processam velocidade de suspensão, pitch de vibração, velocidade das rodas e RPM simultaneamente. Quando o simulador empacota múltiplas atualizações de física em um único frame, todas são processadas em sequência. <1ms de tempo de processamento.

3

Saída de Áudio ASIO

A saída via ASIO ignora completamente a pilha de áudio do Windows. 1,3ms de latência de saída de áudio. Sem middleware de áudio de propósito geral, sem overhead do modo compartilhado WASAPI, sem mixagem do SÓ.

4

Interface de Áudio, Amplificador e Shakers

Funciona com qualquer interface de áudio compatível com ASIO. LF, RF, LR, RR mapeados independentemente. ~1ms de overhead de hardware. Total: a partir de 2ms ponta a ponta.

Latência ponta a ponta por simulador

A latência total depende da taxa de telemetria e estrutura de frames do simulador. A saída ASIO e o overhead de hardware (~2,3ms combinados) são constantes em todos os simuladores; a variável é a idade da telemetria.

Simulador
Faixa ponta a ponta
Taxa de telemetria
A 200 km/h
iRacing
5–19ms
Sub-amostra 360Hz
Menos de 1 metro
ACC
2–9ms
Snapshot por frame
Menos de 0,5 metro
AC
2–9ms
Snapshot por frame
Menos de 0,5 metro

O modelo de sub-amostras a 360Hz do iRacing significa que o dado mais recente em qualquer frame tem apenas 2,78ms no momento do commit; o mais antigo tem 16,67ms. Com ~1,3ms de saída ASIO e ~1ms de overhead de hardware, a faixa completa é 5 a 19ms. ACC e AC usam snapshot por frame: o jogo escreve uma atualização de telemetria por frame desenhado na tela. A 144 FPS o intervalo de frames é 6,9ms, então com ~2,3ms de overhead da pilha a faixa é 2 a 9ms. FPS mais alto entrega telemetria mais fresca; a 60 FPS a faixa se amplia para ~2 a 19ms.

Fontes e Notas
  1. 140 a 200ms medidos em mais de 7 placas de som: Fórum do SimHub, "Usage of low latency áudio driver"
  2. Taxa de atualização de 60Hz do SimHub: Overtake.gg, discussão sobre perfil ShakeIt AM ("SimHub maximum refresh rate is 60Hz")
  3. Padrões de buffer e fórmula de latência do FMOD: FMOD Engine API, documentação System::setDSPBufferSize. Uso do FMOD visível em logs de erro de software háptico ("Disposing FMOD output / Allocating FMOD output").
  4. Piso de mais de 20ms do WASAPI modo compartilhado independentemente do tamanho do buffer: FlexASIO GitHub issue #55
  5. Microsoft IAudioClient3 e WASAPI de baixa latência do Windows 10/11: Microsoft Learn, Low Latency Áudio (Windows drivers)

Baixe o Track Impulse Grátis

Instale o Track Impulse, o software de bass shaker de baixa latência construído para fechar essa lacuna, junto com qualquer setup háptico existente e compare diretamente. Gratuito durante o beta. Sem cartão de crédito. Configure em menos de 10 minutos.