Como a Latencia Haptica Funciona

A Pilha de Latencia.
Por Que o Software de
Bass Shaker e Lento.

Testes da comunidade medem consistentemente 140 a 200ms de latencia ponta a ponta em software padrao de bass shaker para sim racing, em diversas placas de som e configuracoes de hardware. Esta pagina analisa cada camada responsavel, com numeros documentados quando disponiveis e claramente sinalizados quando nao.

Explicado Arquitetura de audio 12 min de leitura
Neste guia

Cada Etapa
Adiciona Latencia.

O feedback haptico e uma cadeia desde o evento do jogo ate o movimento fisico do shaker. No software haptico padrao, tres camadas dominam o atraso total. Nenhuma camada isolada e catastrofica; o problema e que elas se somam.

Escopo e precisao

O valor de 140 a 200ms vem de medicoes da comunidade em mais de 7 configuracoes de placas de som. Os valores por camada abaixo sao documentados ou calculados a partir de fontes tecnicas publicas. Quando os valores sao estimativas ou derivados de principios basicos, isso e indicado no texto.

Motor do Simulador (iRacing, ACC, AC)
Jogo calcula a fisica e disponibiliza os dados
~0ms
↓ loop de polling de telemetria
Loop de Telemetria do Software de Bass Shaker
Software verifica novos dados ate 60 vezes por segundo
0 – 16.7ms
↓ processa efeitos e envia ao motor de audio
Motor de Audio de Proposito Geral
Audio e enfileirado em buffers internos grandes antes da saida
~50ms media
↓ mixer de audio do Windows
WASAPI Modo Compartilhado do Windows
SO mixa audio de todos os aplicativos antes da saida para o hardware
>20ms piso
↓ placa de som, amplificador e shakers
Interface de Audio, Amplificador e Shakers
Conversao de hardware: desprezivel neste contexto
~1–3ms

Total medido: 140-200ms.[1]

16,7ms Por Tick.
Todo Tick.

Antes de qualquer audio 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 saida de audio.

A taxa de atualizacao de propriedades do software padrao de bass shaker roda a ate 60Hz.[2] A 60Hz, uma verificacao ocorre a cada 16,7ms. Um evento que chega imediatamente apos uma verificacao ter acabado de disparar vai esperar os 16,7ms completos ate a proxima antes de acionar qualquer saida haptica. Em media, isso adiciona ~8ms de tempo de espera.

Isso e diferente da propria taxa de telemetria do jogo. O iRacing escreve na memoria compartilhada (uma regiao 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 e o software de bass shaker lendo os dados, nao o simulador produzindo.

Comparacao com o Track Impulse

O Track Impulse le a memoria compartilhada do iRacing usando um modelo orientado a eventos. Nao ha loop de polling. O motor acorda no instante em que nova telemetria e escrita, tipicamente em menos de 1ms do tick de fisica do jogo.

Buffers Grandes,
Por Design.

Antes do som chegar aos seus alto-falantes ou shakers, ele passa por um motor de audio: software que mixa, armazena em buffer e processa o audio. Software padrao de bass shaker usa um motor de audio de proposito geral projetado para trilhas sonoras de jogos e audio cinematico. Esses motores priorizam estabilidade sobre velocidade e usam buffers internos grandes para evitar falhas de audio.

Logs de erro de software padrao de bass shaker mostram chamadas de inicializacao de audio consistentes com o FMOD, um motor de audio amplamente utilizado.[3] A documentacao oficial da API do FMOD afirma que suas configuracoes padrao de buffer interno enfileiram audio em 4 blocos de ~21ms cada. Veja como isso fica em numeros:

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 documentacao do FMOD confirma a formula de latencia como (numbuffers - 1.5) x blocksize, resultando em aproximadamente 53ms de latencia media do mixer nas configuracoes padrao, antes de qualquer overhead de audio do SO ser aplicado.[3]

Ressalva

Nao podemos confirmar a configuracao exata usada por qualquer aplicativo haptico de terceiros; o tamanho do buffer e a contagem de blocos podem diferir dos padroes do FMOD. Os numeros acima ilustram a categoria do problema, nao necessariamente a contribuicao precisa em qualquer produto especifico. O total de 140 a 200ms e medido pela comunidade, nao calculado a partir desses valores por camada.

O Mixer do SO
Sempre Custa Algo.

WASAPI (Windows Audio Session API) e como a maioria dos aplicativos Windows envia audio para sua placa de som. No modo compartilhado, o padrao usado pela maioria dos aplicativos, o Windows roteia o audio de multiplos apps atraves de um mixer central antes de qualquer coisa chegar ao hardware. Essa etapa de mixagem adiciona atraso que voce nao consegue remover alterando configuracoes de buffer.

Testes independentes usando FlexASIO mostram consistentemente que o modo compartilhado do WASAPI produz latencia superior a 20ms independentemente do tamanho do buffer.[4] Esse e um piso imposto pelo proprio Windows, nao um parametro ajustavel.

O Windows nao pode corrigir isso?

A Microsoft adicionou uma opcao de audio de baixa latencia no Windows 10/11 que teoricamente pode reduzir isso para ate 1,3ms. No entanto, tanto o aplicativo quanto o driver da sua placa de som precisam ter suporte especifico. Software padrao de bass shaker nao utiliza isso.[5]

Direto ao Hardware.
Sem Mixer do SO.

ASIO (Audio Stream Input/Output) foi desenvolvido pela Steinberg especificamente para resolver o problema de latencia de audio do Windows para producao musical em tempo real. Sua principal diferenca arquitetural: ele ignora completamente o mixer de audio do Windows e se comunica diretamente com o driver da sua placa de som.

Propriedade
WASAPI Compartilhado
WASAPI Exclusivo
ASIO (driver nativo)
Latencia minima pratica
>20ms piso
~4–10ms
~1,3ms
Mixagem do SO Windows
Sim, todos os apps mixados
Nao
Nao, direto ao hardware
Modelo de callback
Gerenciado pelo SO
Gerenciado pelo SO
Direto do hardware

A 64 amostras / 48kHz (uma configuracao tipica de ASIO), a latencia de saida de audio e 64 / 48000 x 1000 = 1,33ms. Esse e o valor que o Track Impulse consegue atingir com um buffer ASIO de 64 amostras.

Construido 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 esta pronta. Sem atraso de polling. O iRacing entrega sub-amostras a 360Hz (multiplos snapshots de fisica empacotados em cada frame) por esse metodo. ACC e AC entregam um snapshot por frame renderizado, entao 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 suspensao, pitch de vibracao, velocidade das rodas e RPM simultaneamente. Quando o simulador empacota multiplas atualizacoes de fisica em um unico frame, todas sao processadas em sequencia. <1ms de tempo de processamento.

3

Saida de Audio ASIO

A saida via ASIO ignora completamente a pilha de audio do Windows. 1,3ms de latencia de saida de audio. Sem middleware de audio de proposito geral, sem overhead do modo compartilhado WASAPI, sem mixagem do SO.

4

Interface de Audio, Amplificador e Shakers

Funciona com qualquer interface de audio compativel com ASIO. LF, RF, LR, RR mapeados independentemente. ~1ms de overhead de hardware. Total: a partir de 2ms ponta a ponta.

Latencia ponta a ponta por simulador

A latencia total depende da taxa de telemetria e estrutura de frames do simulador. A saida ASIO e o overhead de hardware (~2,3ms combinados) sao constantes em todos os simuladores; a variavel e 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 saida ASIO e ~1ms de overhead de hardware, a faixa completa e 5 a 19ms. ACC e AC usam snapshot por frame: o jogo escreve uma atualizacao de telemetria por frame desenhado na tela. A 144 FPS o intervalo de frames e 6,9ms, entao com ~2,3ms de overhead da pilha a faixa e 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: Forum do SimHub, "Usage of low latency audio driver"
  2. Taxa de atualizacao de 60Hz do SimHub: Overtake.gg, discussao sobre perfil ShakeIt AM ("SimHub maximum refresh rate is 60Hz")
  3. Padroes de buffer e formula de latencia do FMOD: FMOD Engine API, documentacao System::setDSPBufferSize. Uso do FMOD visivel em logs de erro de software haptico ("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 latencia do Windows 10/11: Microsoft Learn, Low Latency Audio (Windows drivers)

Baixe o Track Impulse Gratis

Instale o Track Impulse, o software de bass shaker de baixa latencia construido para fechar essa lacuna, junto com qualquer setup haptico existente e compare diretamente. Gratuito durante o beta. Sem cartao de credito. Configure em menos de 10 minutos.