I test della community misurano costantemente 140-200ms di latenza end-to-end dal software standard per bass shaker nel sim racing, su diverse schede audio e configurazioni hardware. Questa pagina analizza ogni livello responsabile, con dati documentati dove disponibili e chiaramente segnalati dove non lo sono.
Il feedback aptico e una catena che va dall'evento di gioco al movimento fisico dello shaker. Nel software aptico standard, tre livelli dominano il ritardo totale. Nessun singolo livello e catastrofico da solo. Il problema e che si sommano.
Il dato di 140-200ms proviene da misurazioni della community su oltre 7 configurazioni di schede audio. I valori livello per livello riportati sotto sono documentati o calcolati da fonti tecniche pubbliche. Dove i dati sono stime o derivati da principi di base, questo viene indicato nel testo.
Totale misurato: 140-200ms.[1]
Prima che venga sintetizzato qualsiasi audio, il software per bass shaker deve sapere che e successo qualcosa nel simulatore. La maggior parte dei software per bass shaker usa un modello di polling: controlla la presenza di nuovi dati con un timer fisso, elabora gli effetti e scrive l'output audio.
La frequenza di aggiornamento delle proprieta del software aptico standard arriva fino a 60Hz.[2] A 60Hz, un controllo si attiva ogni 16,7ms. Un evento che arriva subito dopo un controllo appena eseguito dovra attendere i 16,7ms completi per il successivo prima di attivare qualsiasi output aptico. In media, questo aggiunge circa 8ms di tempo di attesa.
Questo e distinto dalla frequenza di telemetria del gioco stesso. iRacing scrive nella memoria condivisa (una regione della RAM del PC dove il gioco pubblica la telemetria in tempo reale) a 360Hz tramite sub-campioni. ACC e AC scrivono uno snapshot per frame renderizzato, tipicamente 60-240Hz a seconda degli FPS. In ogni caso, il collo di bottiglia e il software per bass shaker che legge i dati, non il simulatore che li produce.
Track Impulse legge la memoria condivisa di iRacing usando un modello event-driven. Non c'e nessun loop di polling. Il motore si attiva nel momento in cui viene scritta nuova telemetria, tipicamente entro 1ms dal tick fisico del gioco.
Prima che il suono raggiunga le casse o gli shaker, passa attraverso un motore audio: un software che mixa, bufferizza ed elabora l'audio. Il software standard per bass shaker utilizza un motore audio generico progettato per colonne sonore di giochi e audio cinematografico. Questi motori danno priorita alla stabilita rispetto alla velocita e usano buffer interni grandi per prevenire interruzioni audio.
I log di crash del software aptico standard mostrano chiamate di inizializzazione audio coerenti con FMOD, un motore audio molto diffuso.[3] La documentazione API ufficiale di FMOD indica che le impostazioni predefinite del buffer interno accodano l'audio attraverso 4 blocchi di circa 21ms ciascuno. Ecco come si traduce in numeri:
// 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
La documentazione di FMOD conferma la formula di latenza come (numbuffers - 1.5) x blocksize, che produce circa 53ms di latenza media del mixer con le impostazioni predefinite, prima ancora che venga applicato qualsiasi overhead audio del sistema operativo.[3]
Non possiamo confermare la configurazione esatta usata da nessuna applicazione aptica di terze parti. La dimensione del buffer e il numero di blocchi possono differire dai valori predefiniti di FMOD. I numeri sopra illustrano la categoria del problema, non necessariamente il contributo preciso in ogni prodotto specifico. Il totale di 140-200ms e misurato dalla community, non calcolato da questi valori per livello.
WASAPI (Windows Audio Session API) e il modo in cui la maggior parte delle applicazioni Windows invia l'audio alla scheda audio. In modalita condivisa, quella usata dalla maggior parte delle applicazioni, Windows instrada l'audio di piu app attraverso un mixer centrale prima che qualsiasi cosa raggiunga l'hardware. Questo passaggio di mixaggio aggiunge un ritardo che non si puo rimuovere modificando le impostazioni del buffer.
I test indipendenti con FlexASIO mostrano costantemente che la modalita condivisa WASAPI produce una latenza superiore a 20ms indipendentemente dalla dimensione del buffer.[4] Questo e un limite imposto da Windows stesso, non un parametro configurabile.
Microsoft ha aggiunto un'opzione audio a bassa latenza in Windows 10/11 che teoricamente puo ridurre il ritardo fino a 1,3ms. Tuttavia, sia l'applicazione che il driver della scheda audio devono supportarla specificamente. Il software aptico standard non la utilizza.[5]
ASIO (Audio Stream Input/Output) e stato sviluppato da Steinberg specificamente per risolvere il problema della latenza audio di Windows nella produzione musicale in tempo reale. La differenza architettonica chiave: bypassa completamente il mixer audio di Windows e comunica direttamente con il driver della scheda audio.
A 64 campioni / 48kHz (un'impostazione ASIO tipica), la latenza dell'output audio e 64 / 48000 x 1000 = 1,33ms. Questo e il valore che Track Impulse raggiunge con un buffer ASIO di 64 campioni.
Track Impulse affronta direttamente ogni livello dello stack:
Invece di controllare nuovi dati con un timer, Track Impulse resta in ascolto diretto: il gioco comunica al motore il momento esatto in cui la nuova telemetria e pronta. Nessun ritardo di polling. iRacing fornisce sub-campioni a 360Hz (piu snapshot fisici racchiusi in ogni frame) tramite questo metodo. ACC e AC forniscono uno snapshot per frame renderizzato, quindi la freschezza della telemetria scala con i tuoi FPS.
Quattro motori di effetti indipendenti (uno per ogni angolo dell'auto) elaborano velocita degli ammortizzatori, frequenza del rombo, velocita delle ruote e RPM simultaneamente. Quando il simulatore compatta piu aggiornamenti fisici in un singolo frame, vengono tutti elaborati in sequenza. <1ms di tempo di elaborazione.
L'output via ASIO bypassa completamente lo stack audio di Windows. 1,3ms di latenza dell'output audio. Nessun middleware audio generico, nessun overhead della modalita condivisa WASAPI, nessun mixaggio del sistema operativo.
Compatibile con qualsiasi interfaccia audio ASIO. LF, RF, LR, RR mappati indipendentemente. Circa 1ms di overhead hardware. Totale: fino a 2ms end-to-end.
La latenza totale dipende dalla frequenza di telemetria del simulatore e dalla struttura dei frame. L'output ASIO e l'overhead hardware (circa 2,3ms combinati) sono costanti su tutti i simulatori. La variabile e l'eta della telemetria.
Il modello di sub-campionamento a 360Hz di iRacing significa che il dato piu recente in ogni frame ha solo 2,78ms al momento della consegna, mentre il piu vecchio ne ha 16,67ms. Con circa 1,3ms di output ASIO e circa 1ms di overhead hardware, l'intervallo completo e 5-19ms. ACC e AC usano uno snapshot per frame: il gioco scrive un aggiornamento telemetrico per ogni frame che disegna sullo schermo. A 144 FPS l'intervallo tra frame e 6,9ms, quindi con circa 2,3ms di overhead dello stack l'intervallo e 2-9ms. FPS piu alti producono telemetria piu fresca. A 60 FPS l'intervallo si allarga a circa 2-19ms.
Installa Track Impulse, il software per bass shaker a bassa latenza costruito per colmare questo divario, insieme a qualsiasi setup aptico esistente e confronta direttamente. Gratuito durante la beta. Nessuna carta di credito richiesta. Configurazione in meno di 10 minuti.