Latenza audio: misurare il ritardo di microfono e altoparlanti

Pubblicato il 2026-04-13 8 min di lettura

Riepilogo (TL;DR)

Registrare una ripresa di chitarra acustica attraverso la mia vecchia interfaccia USB atterrava da qualche parte intorno ai 35 ms di latenza round-trip nelle cuffie di monitoring – abbastanza che qualsiasi frase ritmica sembrava guadare attraverso sabbia bagnata. Passando a una MOTU M2 con un driver ASIO configurato correttamente ho abbassato quello nell’intervallo dei 5 ms, e la stessa ripresa è passata immediatamente da “impossibile da suonare” a “naturale”. Il fenomeno non è un bug; è una realtà fisica misurabile chiamata latenza round-trip (RTT). RTT è la somma di cinque stadi: il segnale del microfono che riempie un buffer di input, il software host che elabora quel buffer, il segnale elaborato che riempie un buffer di output, il DAC che lo converte di nuovo in analogico, e il suono finale che si propaga attraverso l’aria al tuo orecchio (circa 1 ms per ogni 34 cm). La parte regolabile vive principalmente nella dimensione del buffer e nel modello di driver; ASIO, WASAPI Exclusive, Core Audio e JACK hanno ciascuno minimi tipici diversi e limiti di piattaforma. Questa guida spiega come quei componenti si sommano, perché il compromesso sample-rate/dimensione-buffer non è intuitivo come sembra, e come misurare la latenza end-to-end reale con un cavo loopback, un tono di test e un editor audio – piuttosto che fidarsi dei claim “1 ms” del marketing.

Contesto e concetti

Tra un microfono e un altoparlante, un computer fa più di quanto la maggior parte delle persone realizzi. Un ADC campiona il segnale del microfono a un sample rate scelto (comunemente 48 kHz) e raccoglie i campioni in un buffer di input. Una volta che il buffer si riempie – diciamo, 128 campioni a 48 kHz, circa 2,67 ms di audio – il driver lo consegna all’applicazione.

L’applicazione (un DAW, un client di comunicazione, un browser) elabora il buffer, applica effetti o codifica per la trasmissione di rete, e scrive il risultato in un buffer di output. Quando il buffer di output si riempie, il DAC lo converte in un segnale analogico che lascia l’uscita cuffie o linea.

Poi c’è il mondo fuori dal computer. Il suono viaggia a circa 343 m/s a temperatura ambiente, il che significa circa 1 ms per 34 cm. Le cuffie aggiungono essenzialmente nulla di questo; un altoparlante monitor attraverso la stanza aggiunge qualche millisecondo sopra tutto il resto. Una coppia di monitor a 1,7 m di distanza di ascolto contribuisce con circa 5 ms di pura propagazione – invisibile sul foglio delle specifiche ma presente nelle tue orecchie.

Quindi latenza round-trip = buffer di input + elaborazione + buffer di output + DAC + propagazione. Con il sample rate fisso, buffer più piccoli riducono la latenza ma alzano il carico CPU, perché il thread audio deve svegliarsi più spesso. Se la dimensione del buffer è specificata in campioni piuttosto che in tempo, alzare il sample rate accorcia lo stesso buffer di “N campioni” in millisecondi, ma sample rate più alti alzano anche il throughput e stressano i driver in modo diverso, quindi questo non è un modo gratuito per ridurre il ritardo.

Il modello di driver sta tra l’applicazione e l’hardware audio e ha le sue proprie caratteristiche di latenza. Su Windows, i percorsi classici MME e DirectSound aggiungono buffering sostanziale per compatibilità; WASAPI Shared è più basso ma ancora mediato dal mixer; WASAPI Exclusive e ASIO aggirano molto di quel sovraccarico. ASIO4ALL è un wrapper ASIO generico che aiuta quando un driver ASIO del venditore non è disponibile, ma non è un sostituto di un vero driver ASIO del venditore – il RTT misurato sulla stessa Focusrite Scarlett 2i2 3rd Gen tipicamente atterra significativamente più basso con il driver ufficiale che con ASIO4ALL sopra WASAPI. Su macOS, Core Audio è già calibrato per bassa latenza come default di piattaforma. Su Linux, gli stack JACK e PipeWire possono raggiungere latenza molto bassa una volta configurati, ma richiedono schedulazione kernel real-time per essere consistenti.

Confronto e dati

CriterioASIOWASAPI ExclusiveCore AudioJACK
PiattaformaPrincipalmente WindowsSolo WindowsSolo macOSLinux-centrico, esistono port cross-platform
Latenza più bassa tipicaMolto bassa, comunemente nell’intervallo di pochi millisecondiBassa quando usato in modalità esclusivaBassa e stabile nell’intervallo di pochi millisecondiMolto bassa quando ben configurata, con più complessità di setup
Modello di condivisioneDipende dal driver (tipicamente esclusivo)Condiviso o esclusivo; esclusivo è minore latenzaLa modalità condivisa ben calibrata è il defaultBasato su matrice di routing, multi-client

I numeri esatti in millisecondi dipendono fortemente da hardware, driver e versione SO, quindi piuttosto che fidarsi della linea “1 ms di latenza” su una pagina di prodotto, misura il tuo sistema una volta per stabilire una baseline. Interfacce accessibili come la MOTU M2 e la Focusrite Scarlett 2i2 3rd Gen possono raggiungere round-trip a cifra singola in millisecondi quando abbinati a un driver ASIO o Core Audio appropriato, ma lo stesso hardware su un percorso WASAPI in modalità condivisa Windows o avvolto attraverso ASIO4ALL tipicamente performa notevolmente peggio. Il tuo RTT reale è il risultato congiunto di tre variabili – interfaccia, driver, dimensione del buffer – e assumere una qualsiasi di esse in isolamento è raramente accurato.

Scenari reali

Scenario 1 — Performance dal vivo e monitoring in-ear. Un cantante che ascolta la propria voce attraverso monitor in-ear sentirà un ritardo anche di pochi millisecondi come un problema di timing. Il target qui è RTT sotto i 10 ms, che solitamente richiede dimensioni di buffer basse, un driver a bassa latenza (ASIO su Windows, Core Audio su macOS) e – dove possibile – il direct monitoring hardware dell’interfaccia, che aggira il percorso software interamente per il segnale di monitoring. La manopola monitor sul pannello frontale della MOTU M2 risolve questo in un giro, e l’interruttore “Direct” della Scarlett 2i2 3rd Gen fa lo stesso.

Scenario 2 — Registrazione podcast. A meno che diversi host si stiano monitorando l’un l’altro dal vivo, 50–100 ms di RTT sono solitamente fine durante la sessione di registrazione. La post-produzione allinea comunque le tracce, e un buffer più grande migliora l’headroom CPU, che a sua volta riduce il rischio di dropout in una registrazione lunga. Ottimizzare per la latenza più bassa qui spesso danneggia piuttosto che aiutare.

Scenario 3 — Videoconferenza. Le chiamate WebRTC basate su browser tipicamente operano in un intervallo da circa 100 a 200 ms end-to-end a causa di rete, codifica e jitter buffering sopra la latenza audio locale. Questo si trova vicino al confine dove il turn-taking conversazionale sembra naturale; aggiungere auricolari Bluetooth con un codec più vecchio può spingerlo oltre quella soglia, motivo per cui i partecipanti iniziano a parlarsi sopra.

Scenario 4 — Collaborazione musicale online. Tentare di suonare musica sincronizzata con un partner remoto su internet è l’estremo implacabile di questo spettro. Oltre circa 25–30 ms di ritardo one-way, mantenere un tempo stabile diventa difficile, e internet domestico tipico più software audio consumer regolarmente atterra ben sopra quello. Piattaforme di collaborazione a bassa latenza dedicate esistono specificamente per radere via ogni millisecondo possibile, e anche allora richiedono generalmente ethernet cablato, calibrazione attenta del driver e prossimità fisica sulla dorsale di internet. Riconoscere che uno stack di videochiamata consumer sia lo strumento sbagliato per questo lavoro è solitamente il primo passo.

Errori comuni

“L’audio Bluetooth è sempre ad alta latenza.” Lo streaming A2DP classico aggiunge ritardo significativo. Ma i codec più recenti LE Audio (LC3) e aptX Low Latency portano questo considerevolmente più basso, che è un cambio di categoria nella performance sentita. Due cuffie che dicono entrambe “Bluetooth” possono differire drammaticamente a seconda del codec che loro e la sorgente supportano. Per monitorare una sessione di registrazione, però, il cablato resta la scelta più sicura.

“L’audio USB è sempre meglio dell’analogico.” L’audio USB batte l’analogico onboard quando l’interfaccia ha un buon DAC, preamp puliti e driver stabili. I DAC USB economici possono effettivamente essere peggio a causa di jitter, rumore e problemi di driver. “USB” da solo non implica qualità; la scelta dei componenti sì.

“Il sample rate a 192 kHz è a latenza più bassa.” Controintuitivo ma importante: se il buffer è specificato in tempo (ms), alzare il sample rate non riduce la latenza fisica. Solo quando il buffer è fisso in campioni un sample rate più alto significa meno millisecondi per buffer – al costo di più dati al secondo, più CPU e più stress sul driver. La bassa latenza viene principalmente da buffer più piccoli e un migliore modello di driver, non da un sample rate più alto.

“Software monitoring e hardware monitoring si sentono uguali.” Non lo fanno. Il software monitoring instrada il segnale del microfono attraverso il percorso DAW – buffer di input, elaborazione plugin, buffer di output – e accumula RTT lungo la strada. L’hardware monitoring su un’interfaccia audio invia il segnale del microfono direttamente all’uscita cuffie dentro l’interfaccia, aggirando il computer interamente per il percorso di monitoring. Il performer si sente con effettivamente zero latenza, mentre il computer registra ancora la traccia per la produzione successiva. Molti setup confondono i due e incolpano la dimensione del buffer per un ritardo che l’hardware monitoring eliminerebbe in un cambio di impostazione.

Lista di controllo

  1. Definisci il target RTT per il tuo caso d’uso. Performance dal vivo: sotto 10 ms; registrazione: 50–100 ms va bene; conferenza: 100–200 ms è realistico.
  2. Scegli il modello di driver. Su Windows, ASIO o WASAPI Exclusive; su macOS, Core Audio; su Linux, JACK o PipeWire. Gli stack di default in modalità condivisa (MME, WASAPI condiviso di default) solitamente hanno la latenza più alta.
  3. Abbassa la dimensione del buffer incrementalmente fino a poco prima che iniziano i dropout. Quello è il pavimento pratico del tuo sistema.
  4. Fai una misurazione di loopback. Collega l’uscita dell’interfaccia al suo ingresso con un cavo, suona un tono di test, e leggi il ritardo dalla forma d’onda catturata in un editor audio.
  5. Abbina il sample rate alla necessità del progetto. 48 kHz è tipico per il lavoro video; 44,1/48 kHz per la musica. Vai sopra solo con una ragione specifica.
  6. Usa il percorso di monitoring saggiamente. Dove possibile, usa la funzione di direct monitoring dell’interfaccia per le orecchie del performer, che rende il monitoring RTT effettivamente zero anche se il percorso di registrazione ha diversi millisecondi di latenza.

Strumento correlato

Lo strumento di latenza audio di Patrache Studio stima la latenza round-trip nel browser, il che rende facile ottenere una lettura approssimativa senza comprare hardware. Per il quadro più ampio di “latenza di input” in un contesto di gaming, vedi NKRO della tastiera e input lag per il gaming. Se stai calibrando un setup di videochiamata dove il ritardo audio influisce sulla sincronia A/V, abbina questa guida a Diagnostica webcam: frame rate, risoluzione e illuminazione per capire la latenza lato camera che si impila sopra l’audio.

Riferimenti

Strumento correlato

diagno.patrache.studio/audio/latency/