Latenza audio di loopback: ciò che il test non rivela mai

La maggior parte dei test audio verifica solo che il suono venga riprodotto e che il microfono catturi. Nessuno misura la latenza di andata e ritorno: il tempo da un evento audio che entra dal microfono al segnale elaborato che esce dagli altoparlanti. Questo singolo numero decide se un musicista può registrare su una traccia click, se una videochiamata risulta naturale e se l'audio spaziale nei giochi è preciso. Un sistema può superare ogni test di riproduzione mostrando una latenza catastrofica, perché funzionalità e tempismo sono assi separati. Questa guida spiega come misurare la latenza di andata e ritorno, cosa significano i numeri e come ridurla.

Ogni controllo hardware inizia allo stesso modo. Nuovi altoparlanti, test del tono, conferma che esce il suono, avanti. Microfono, parlare, vedere il livello muoversi, avanti. Questi due test confermano che il percorso di uscita e il percorso di ingresso funzionano. Nessuno misura la domanda che decide davvero se il tuo setup audio può gestire il lavoro vero: quanto tempo impiega un suono ad andare dal microfono, attraverso il computer, e uscire dagli altoparlanti?

Quel numero è la latenza di andata e ritorno, e decide in silenzio quali compiti il tuo sistema può onestamente gestire:

  • Registrare musica. Suonare su un click o un accompagnamento richiede che il tuo stesso suono torni alle tue orecchie quasi immediatamente. Oltre circa quaranta millisecondi di andata e ritorno, sbandi dal tempo, ogni take suona pesante e nessun esercizio lo risolve. Le interfacce audio che condividono un controller USB con altri dispositivi possono anche soffrire di contesa della larghezza di banda USB, che aggiunge picchi di latenza ai ritardi del buffer.
  • Tenere conversazioni. Le videochiamate risultano naturali solo se la catena audio è stretta. Un ritardo eccessivo produce eco, parole sovrapposte e il ritmo a scatti di una chiamata satellitare.
  • Giocare con audio spaziale. Il suono posizionale funziona solo se l’audio arriva sincronizzato con ciò che è visibile. Quando il percorso audio resta indietro rispetto allo schermo, passi e spari si staccano dall’azione sullo schermo.

Il tuo test degli altoparlanti e il tuo test del microfono rispondono «funziona?». Il test di latenza del loop risponde «quanto veloce?». Questa pagina spiega cos’è la latenza di andata e ritorno, da dove viene e come ridurla. I numeri qui provengono dall’esperienza generale su molte configurazioni hardware e software: un vero setup ASIO su un Focusrite Scarlett 2i2 dà valori diversi da un codec Realtek integrato su Windows 11. I tuoi risultati variano con interfaccia, driver e configurazione del buffer. Interfaccia audio professionale con cuffie e microfono, che mostra un setup da studio per misurare la latenza

Il test degli altoparlanti non misura la latenza

Un test degli altoparlanti riproduce un tono, uno sweep o una canzone attraverso il percorso di uscita e conferma che viene prodotto del suono. È un test di funzionalità con esito binario: cavo collegato, driver caricato, volume non muto, convertitore digitale-analogico vivo. Se senti il tono, il percorso di uscita funziona. Nient’altro dice il test.

Un test del microfono fa lo stesso per la direzione di ingresso. Cattura ciò che dici, mostra un livello e conferma che microfono, preamplificatore e convertitore analogico-digitale funzionano. Anche qui l’esito è binario.

La misurazione della latenza è un altro tipo di test. Invece di chiedere se un segnale può attraversare un percorso, chiede quanto dura l’attraversamento. La procedura è semplice: invia un segnale noto — un impulso, un clic, una breve raffica — attraverso l’uscita, catturalo all’ingresso e calcola la differenza di tempo tra invio e ricezione. Quella differenza è la latenza di andata e ritorno, in millisecondi.

La distinzione conta perché le due misurazioni sono indipendenti. Un sistema può superare ogni test di riproduzione mostrando una latenza catastrofica. Gli altoparlanti Bluetooth sono l’esempio classico: riproducono un tono fedelmente, il test degli altoparlanti segnala successo, mentre il codec wireless aggiunge cento a centottanta millisecondi di ritardo che nessun test di riproduzione nota mai. Un tono che arriva centocinquanta millisecondi in ritardo viene tecnicamente riprodotto.

Ecco perché l’assunzione abituale — «i miei altoparlanti suonano bene, quindi il mio sistema audio è buono» — crolla su tutto ciò che è sensibile al timing. Funzionalità e tempismo sono assi separati. Prima di fidarti del tuo setup per registrazione, chiamate o gioco, ti serve il numero che i test di riproduzione non possono strutturalmente fornire.

Guarda i buffer riempirsi

La latenza di andata e ritorno non è un singolo ritardo. È la somma dei ritardi in ogni stadio tra la capsula del microfono e la membrana dell’altoparlante. Capire il percorso ti mostra dove sono nascosti i tuoi millisecondi:

  1. Buffer di ingresso. Il convertitore analogico-digitale campiona continuamente, ma il sistema operativo consegna l’audio a blocchi. Il driver aspetta che il buffer sia pieno prima di passare i dati all’applicazione. A 48 kHz, un buffer di 128 campioni impiega 2,7 millisecondi a riempirsi: tanto aspetta il tuo audio prima che qualcuno lo elabori. La maggior parte dei sistemi tiene due o tre buffer in circolazione. Conta circa cinque a otto millisecondi prima che la tua applicazione veda il primo campione.
  2. Conversione analogico-digitale. Il convertitore ha bisogno di tempo per campionare, quantizzare e sincronizzare. Sull’hardware consumer contribuisce tipicamente da uno a tre millisecondi; le interfacce dedicate fanno meglio.
  3. Pianificazione del sistema operativo. Il motore audio sveglia la tua applicazione tramite timer, e il risveglio è soggetto alla normale pianificazione dei thread. In modalità condivisa, il sistema operativo mixa anche il tuo flusso con ogni altra sorgente audio del sistema, aggiungendo una passata di elaborazione propria. Questo stadio contribuisce da pochi millisecondi a venti o più a seconda della piattaforma e del carico. È qui che Linux con PipeWire può superare Windows — e dove un desktop rumoroso può far esplodere silenziosamente la tua latenza.
  4. Elaborazione dell’applicazione. Il software sul lato ricevente — una DAW, una catena di effetti, un grafo audio del browser — elabora il blocco prima di passarlo. Piccolo, ma parte della somma.
  5. Conversione digitale-analogica. Lo specchio dello stadio due, altri uno a tre millisecondi mentre il segnale elaborato diventa tensione analogica.
  6. Buffer di uscita. I campioni elaborati aspettano nel buffer di uscita finché il convertitore è pronto a riprodurli: la matematica dei buffer del lato di ingresso si ripete. Nelle configurazioni tipiche si aggiungono altri cinque a otto millisecondi.

Sommando gli stadi, la latenza di andata e ritorno in modalità condivisa su un computer normale si colloca tipicamente tra trenta e sessanta millisecondi — i valori seguenti sono esempi illustrativi di hardware concreto, non specifiche universali. In test informali su un laptop Windows 11 standard con codec Realtek ALC897 integrato a 128 campioni di buffer, sono state osservate misurazioni in modalità condivisa vicine all’estremità superiore di quel range. Con una Behringer U-Phoria UM2 via ASIO4ALL sullo stesso hardware, la misurazione è scesa a circa quindici millisecondi. Sono osservazioni su una singola macchina senza condizioni controllate; servono come indicatori del divario tipico tra modalità condivisa e percorso ASIO, non come valori garantiti per il tuo hardware. Nessun driver elimina il tempo di conversione — ma l’overhead di buffer e pianificazione che domina la somma si riduce drasticamente. Diagramma del percorso audio di andata e ritorno dal microfono attraverso l'elaborazione del computer fino all'uscita degli altoparlanti

Un numero, due definizioni

Il software audio raramente riporta un singolo numero. Apri le impostazioni di un’applicazione professionale e vedrai tipicamente due: latenza di ingresso, il tempo dal microfono all’applicazione, e latenza di uscita, il tempo dall’applicazione agli altoparlanti. Driver come ASIO riportano entrambi separatamente, e il marketing cita spesso il numero che sta meglio.

La latenza di andata e ritorno è la somma di entrambi più il tempo di elaborazione proprio dell’applicazione. Un sistema che riporta venti millisecondi per lato ha un andata e ritorno di circa quaranta. Un utente che legge «20 ms di latenza» e presume che sia il ritardo udibile sbaglia di un fattore due — e l’errore è comune perché i valori per lato sono sui fogli delle specifiche.

La distinzione conta perché percepisci sempre l’andata e ritorno. Quando un musicista monitora la propria voce o il proprio strumento, il suono deve uscire dal microfono, attraversare il sistema e tornare alle cuffie prima che lo senta. Questo è il percorso completo. Un valore per lato descrive solo metà del viaggio.

Per coerenza, tutti i numeri qui si riferiscono alla latenza di andata e ritorno. Quando confronti la tua misurazione con una specifica di prodotto o un benchmark, verifica sempre che entrambi i numeri descrivano lo stesso tipo di viaggio. Confrontare una misurazione di andata e ritorno con una specifica per lato fa sembrare il tuo sistema due volte più lento di quanto sia.

Il sistema operativo decide prima di te

Lo stesso microfono, gli stessi altoparlanti, lo stesso cavo danno latenze completamente diverse su sistemi operativi diversi, perché ogni piattaforma instrada l’audio attraverso uno stack software diverso. Lo stack decide quanto overhead di buffer e pianificazione si aggiunge all’inevitabile tempo di conversione.

Windows: modalità condivisa, modalità esclusiva e ASIO

Windows offre tre percorsi verso l’hardware, ciascuno con un profilo di latenza diverso:

  • La modalità condivisa WASAPI è il percorso predefinito di ogni applicazione salvo richiesta contraria (Microsoft Learn: WASAPI Shared Mode, 2023). Tutto l’audio viene mixato e consegnato con buffering prudente. La latenza di andata e ritorno abitualmente osservata sui sistemi tipici è tra trentadue e sessantaquattro millisecondi, a seconda della dimensione del buffer e del carico — intervalli di esperienza comuni, non valori garantiti. Web Audio, WebRTC e la riproduzione multimediale prendono percorsi leggermente diversi, ma iniziano tutti da questo mixer comune.
  • La modalità esclusiva WASAPI o ASIO bypassa il mixer e dà a un’applicazione l’accesso diretto al dispositivo, con la latenza che scende tipicamente a circa dieci millisecondi su hardware tipico (Microsoft Learn: WASAPI Exclusive Mode, 2023). Disponibile per le applicazioni native che la richiedono; i browser non possono.
  • ASIO è un protocollo driver che bypassa completamente lo stack audio di Windows e parla direttamente con l’hardware dell’interfaccia (Steinberg: ASIO Host and Driver Guide v2.3, 2021). Con un’interfaccia capace, ASIO raggiunge tipicamente otto a quindici millisecondi, con i numeri esatti che dipendono da interfaccia, versione del driver e configurazione del buffer. I browser non possono usarlo.

macOS: Core Audio

Il framework Core Audio di Apple è ben ottimizzato, e le applicazioni native raggiungono regolarmente otto a venti millisecondi di andata e ritorno con impostazioni di buffer ragionevoli. Il percorso condiviso è efficiente, quindi anche la latenza misurata nel browser è solitamente migliore su macOS che su Windows. Rimane comunque sopra il minimo nativo perché il browser non può rivendicare l’accesso esclusivo al dispositivo né regolare il buffer sulle proprie esigenze.

Linux: ALSA, PulseAudio e PipeWire

La latenza su Linux è un bersaglio mobile. ALSA, l’interfaccia driver di basso livello, è veloce ma specifica per applicazione. PulseAudio ha storicamente aggiunto un overhead di buffering percettibile. PipeWire, il successore moderno, è progettato per l’audio a bassa latenza e può eguagliare o superare le altre piattaforme quando è configurato correttamente — i risultati variano fortemente con distribuzione e configurazione.

Nella maggior parte delle configurazioni, il browser è limitato al percorso condiviso. Non può richiedere modalità esclusive, caricare driver ASIO né aumentare la priorità del suo thread audio. La latenza audio del browser si colloca quindi tipicamente vicino al tetto della modalità condivisa della tua piattaforma — il meglio che il percorso cooperativo può offrire sulle configurazioni standard — mentre il software nativo professionale è costruito per rompere quel limite quando hardware e driver lo permettono.

Cosa significano davvero 60 millisecondi

Un numero grezzo in millisecondi non dice nulla finché non lo mappi su ciò che vuoi fare. Le soglie sotto sono orientamenti generali, non standard di certificazione professionale; l’idoneità reale dipende dal tuo compito, dal tuo setup di monitoraggio e dal tuo ambiente di ascolto. Quattro zone coprono l’intervallo pratico:

  • Sotto 20 ms — eccellente. La produzione musicale professionale è a suo agio qui. I musicisti possono registrare su un click, monitorarsi con effetti e suonare a tempo perché il percorso di ritorno è praticamente istantaneo. L’audio spaziale nei giochi rimane sincronizzato con l’immagine.
  • 20–60 ms — accettabile per la maggior parte degli usi. Podcast, videochiamate, gioco generale e registrazione occasionale funzionano bene. Il tracking musicale di precisione soffre vicino all’estremità superiore: gli esecutori sentono il proprio feedback sonoro trascinarsi leggermente, e il lavoro di precisione diventa notevolmente più difficile oltre circa quaranta millisecondi.
  • 60–120 ms — problematico per la produzione, accettabile per l’uso occasionale. Karaoke, chat vocale e ascolto vanno bene. Registrare su un accompagnamento diventa davvero difficile, e nei giochi il suono inizia a staccarsi dall’azione, minando gli indizi spaziali su cui si basa l’audio spaziale.
  • Oltre 120 ms — pessimo. Il lavoro sensibile al timing è praticamente impossibile. Le chiamate sviluppano eco udibile, le esibizioni sembrano scollegate e l’audio spaziale suona falso anche nell’uso occasionale. Questa zona è la casa naturale dell’audio Bluetooth e dei sistemi in modalità condivisa mal configurati.

I confini delle zone sono questione di giudizio, ma la forma è affidabile: la produzione richiede i numeri più bassi, le conversazioni tollerano di più e l’ascolto occasionale tollera il massimo. La tua misurazione di andata e ritorno colloca il tuo sistema in esattamente una zona, e quel posizionamento ti dice quali usi previsti saranno confortevoli e quali lavoreranno contro di te. Tieni il numero — è il tuo punto di riferimento per ogni ottimizzazione della sezione successiva. Diagramma a codice colore degli intervalli di latenza audio accettabili, da professionale sotto i 20ms a inadeguato oltre i 120ms

Tre leve: frequenza, buffer, driver

Tre controlli decidono dove si accumula la latenza sul tuo percorso, e non hanno la stessa potenza. La frequenza di campionamento fissa il throughput della pipeline — quante volte al secondo viene misurato l’audio — più che il ritardo direttamente. Interagisce con il timing del buffer perché un buffer si misura in campioni: 128 campioni impiegano 2,9 millisecondi a 44,1 kHz, ma solo 1,3 millisecondi a 96 kHz, quindi la stessa dimensione di buffer rappresenta durate diverse a frequenze diverse. Il trucco: una frequenza più alta richiede più elaborazione al secondo, il che spesso ti costringe ad alzare il buffer per la stabilità, annullando il guadagno. Inseguire 96 o 192 kHz impone tipicamente un buffer più grande per mantenere stabile il flusso, il che può annullare il vantaggio teorico o rallentare tutto. Tratta la frequenza come un’impostazione di flusso di lavoro, tipicamente 48 kHz, non come il controllo principale della latenza. 48 kHz è diventato lo standard de facto per l’audio sincronizzato con il video perché si mappa pulitamente sui frame rate video di 24, 25 e 30 fps — ecco perché la pipeline professionale audio-video parte da lì. La dimensione del buffer è la leva principale della latenza. Determina quanto audio si accumula prima dell’elaborazione e appare due volte nell’andata e ritorno — una sul lato di ingresso e una su quello di uscita. Ridurre il buffer della metà dimezza quella parte del ritardo, ma anche il tempo che il sistema ha per consegnare ogni blocco, aumentando il rischio di underrun: clic, scoppiettii e interruzioni. La matrice pratica a 48 kHz è questa:

  • 64 campioni — circa 8–12 ms di andata e ritorno su hardware capace con ASIO o modalità esclusiva. Le interfacce economiche producono spesso clic a questa dimensione.
  • 128 campioni — circa 12–20 ms. Un punto dolce ASIO comune per la produzione.
  • 256 campioni — circa 20–35 ms. Spesso la dimensione stabile più piccola in modalità condivisa.
  • 512 campioni — circa 35–60 ms. Sicuro, ma percettibilmente lento.
  • 1024 campioni — circa 60–100 ms. Solo per streaming o riproduzione dove la latenza non conta. Il driver fissa il pavimento. ASIO e la modalità esclusiva permettono dimensioni di buffer da 32 a 128 campioni; la modalità condivisa parte più in alto; i codec Bluetooth aggiungono cento millisecondi o più prima ancora che i buffer contino. Nessuna regolazione del buffer batte il minimo del driver — ecco perché il driver è la prima leva, non l’ultima.

Il browser non è una DAW

Un browser può stimare la latenza di andata e ritorno con la Web Audio API (MDN: Web Audio API, 2024), che programma un impulso attraverso l’uscita e cattura il segnale in arrivo all’ingresso del microfono. Una tipica misurazione di loop Web Audio su un laptop in modalità condivisa riporta di solito 55–70 ms — un multiplo del valore ASIO — un divario che illustra il contributo del percorso condiviso del browser. Il tempo misurato include il percorso acustico attraverso l’aria, i trasduttori di altoparlante e microfono, la soppressione dell’eco della stanza e l’intero stack audio del sistema. Questo si chiama ritardo acustico di andata e ritorno, ed è il numero rilevante per le chiamate basate sul browser, il karaoke e i giochi nel browser, ma non è la stessa cosa della latenza di andata e ritorno ASIO che misura il software audio professionale. Questa misurazione richiede un vero percorso acustico tra altoparlante e microfono; il controllo automatico del guadagno, la riduzione del rumore e la cancellazione dell’eco possono alterare la forma dell’impulso, mentre distanza dal microfono, riflessi della stanza e impostazioni di volume influenzano il risultato. Quello che il browser non può fare è raggiungere il caso migliore dell’hardware. Deve usare il percorso audio condiviso del sistema operativo, non può rivendicare l’accesso esclusivo al dispositivo, non può caricare driver ASIO né controllare la sua dimensione del buffer audio o la priorità del suo thread. La misurazione riflette quindi il tetto della modalità condivisa della tua piattaforma, non il vero minimo dell’hardware. Quel tetto è esattamente il numero giusto per il lavoro basato sul browser. Le chiamate web, i giochi nel browser, il karaoke web e tutto il resto in una scheda condividono tutti il percorso audio del browser a livello di sistema operativo, con Web Audio, WebRTC e la riproduzione multimediale che differiscono nel dettaglio. Se il numero misurato nel browser è buono, ogni caso d’uso del browser sarà confortevole. Se è pessimo, il software nativo può forse salvarti — ma il browser sarà tipicamente più lento del software nativo sullo stesso hardware e configurazione.

Sei modi per ridurre la latenza

Affronta i problemi in ordine di impatto e fermati quando il tuo numero atterra in una zona con cui puoi convivere:

  1. Correggi prima la modalità del driver. Installa il driver ASIO per la tua interfaccia audio su Windows o passa alla modalità esclusiva WASAPI. È la leva singola più grande ed è gratis.
  2. Riduci la dimensione del buffer. Scendi da 512 a 256 a 128 a 64 campioni, testando ogni impostazione finché non compaiono clic o scoppiettii. Poi torna su di un gradino al buffer più grande che resta pulito.
  3. Controlla la frequenza di campionamento. Usa 48 kHz per musica e montaggio video. Inseguire 96 o 192 kHz impone tipicamente un buffer più grande e finisce più lento.
  4. Chiudi le applicazioni concorrenti. Streaming, registrazione e schede piene rubano tempo CPU al thread audio e causano underrun con buffer piccoli.
  5. Considera un’interfaccia audio. L’hardware dedicato porta convertitori migliori, veri driver ASIO e dimensioni di buffer che l’audio integrato non raggiunge.
  6. Preferisci le connessioni cablate. Per tutto ciò che è sensibile al timing, le cuffie cablate battono il Bluetooth di cento millisecondi o più, indipendentemente da tutte le altre impostazioni. Ogni passo si combina. Passare dalla modalità condivisa a 512 campioni ad ASIO a 128 campioni sposta tipicamente un sistema da cinquanta millisecondi a meno di venti — la differenza tra inutilizzabile e professionale.

Conclusione

Un test di riproduzione conferma che i tuoi altoparlanti funzionano. Un test di loop conferma che funzionano a tempo — e sono domande diverse con risposte diverse. Esegui il test degli altoparlanti per validare il percorso di uscita e il test del microfono per il percorso di ingresso. Nota: questo sito non offre attualmente uno strumento dedicato di misurazione della latenza di loop; l’approccio Web Audio API descritto richiede un’implementazione separata o una configurazione nella console del browser. Usalo per conoscere il ritardo acustico di andata e ritorno che decide se registrazione, conversazione e audio spaziale risultano naturali sulla tua macchina.

Misura una volta e tieni il risultato. Sotto i venti millisecondi significa timing professionale. Da venti a sessanta copre la maggior parte del lavoro quotidiano. Oltre centoventi, ogni compito sensibile al timing lotterà contro di te, e la soluzione inizia di solito dal driver piuttosto che dall’hardware. Se non hai mai misurato il numero, stai tirando a indovinare su ogni compito audio che dipende dal timing.

Domande frequenti

Un test degli altoparlanti può dirmi qualcosa sulla latenza audio?

No. Un test degli altoparlanti riproduce un tono e conferma che esce il suono. Misura se il percorso di uscita funziona, non quanto tempo impiega il segnale ad attraversare la catena di ingresso e uscita. La latenza è una misura di tempo, non un test di funzionalità, e le due cose sono indipendenti: un sistema può superare ogni test di riproduzione mostrando una latenza catastrofica. Per misurare la latenza serve un test di andata e ritorno che invii un impulso noto attraverso l'uscita, catturi il segnale di ritorno all'ingresso e calcoli la differenza di tempo tra trasmissione e ricezione.

Cos'è esattamente la latenza di andata e ritorno?

La latenza di andata e ritorno, chiamata anche ritardo o tempo di andata e ritorno, è il tempo totale da un segnale audio che entra nel sistema dall'ingresso, viene elaborato dal sistema operativo e da qualsiasi applicazione, ed esce dall'uscita. Include il ritardo del buffer di ingresso, il tempo di conversione analogico-digitale, il ritardo di pianificazione del sistema operativo, il ritardo di elaborazione dell'applicazione, il tempo di conversione digitale-analogica e il ritardo del buffer di uscita. Misurata in millisecondi, è il percorso completo dal microfono all'altoparlante. Le misurazioni del browser catturano il percorso acustico attraverso l'aria, mentre ASIO riporta il percorso elettrico interno: non sono lo stesso numero.

La mia latenza misurata è di 80 millisecondi: è negativa per la produzione musicale?

Per la maggior parte delle produzioni musicali è alta. I musicisti che registrano su una traccia di accompagnamento o su un click preferiscono latenze sotto i quaranta millisecondi per suonare a tempo senza un eco percettibile. A ottanta millisecondi il ritardo è chiaramente udibile come uno scarto tra ciò che suoni e ciò che senti di ritorno, rendendo molto difficile mantenere un tempo preciso. Per registrazioni occasionali o podcast il ritardo è percepibile ma spesso tollerabile. Per il monitoraggio dal vivo durante una sessione di registrazione, ottanta millisecondi sono tipicamente inutilizzabili. La tolleranza individuale varia con l'esperienza e il genere.

Perché la latenza misurata nel browser è tipicamente più alta di quella del software audio professionale?

I browser sono progettati per coerenza multipiattaforma e sicurezza, non per la performance audio professionale. Software come Reaper o Ableton può usare i driver ASIO su Windows per bypassare il layer di mixing del sistema operativo e accedere direttamente all'hardware, raggiungendo comunemente latenze di otto a quindici millisecondi. I browser devono passare attraverso il layer audio condiviso, che aggiunge overhead di mixing e pianificazione, e non possono accedere alle modalità esclusive a bassa latenza. Il browser misura il meglio che il percorso condiviso può ottenere, nella maggior parte dei casi superiore a un percorso diretto del driver, anche se il divario varia con hardware, driver e configurazione.

Quanto riduce la latenza un driver ASIO?

Su Windows, passare dalla modalità condivisa WASAPI predefinita ad ASIO o alla modalità esclusiva WASAPI può ridurre la latenza da trenta a sessanta millisecondi a otto a quindici millisecondi. La riduzione esatta dipende dall'interfaccia audio e dalla sua implementazione del driver. ASIO dà all'applicazione accesso diretto ai buffer dell'hardware ed evita il mixer audio di Windows e il suo overhead di buffering associato. Non tutte le schede audio supportano ASIO; l'audio integrato economico tipicamente no. Per il lavoro professionale su Windows, un'interfaccia audio con supporto ASIO è uno degli aggiornamenti più efficaci per la latenza — ma rifletti prima dell'acquisto se il tuo flusso di lavoro ne ha davvero bisogno.

Una frequenza di campionamento più alta significa una latenza più bassa?

Non direttamente. La frequenza di campionamento determina quante volte al secondo viene misurato l'audio, il che influisce sulla risposta in frequenza e sul carico di elaborazione, non sul ritardo del buffer. La dimensione del buffer è il controllo principale della latenza: buffer più piccoli significano meno attesa prima che i dati si accumulino per l'elaborazione. Tuttavia, frequenze più alte aumentano il throughput dei dati a parità di dimensione del buffer, il che può causare underrun se il sistema non tiene il passo. L'approccio pratico: adatta la frequenza al flusso di lavoro, tipicamente 48 kHz, poi minimizza la dimensione del buffer.

Come influisce la dimensione del buffer su latenza e stabilità?

La dimensione del buffer determina quanti campioni audio si accumulano in memoria prima dell'elaborazione. Un buffer più piccolo riduce la latenza ma lascia al sistema meno tempo per consegnare il blocco di dati successivo, aumentando il rischio di underrun: clic, scoppiettii o interruzioni udibili. Un buffer più grande è più stabile ma aggiunge latenza. Il compromesso dipende dall'hardware: un computer veloce con una buona interfaccia può usare buffer da 64 o 128 campioni a bassa latenza senza interruzioni. Un sistema più lento può aver bisogno di 512 o 1024 campioni per rimanere stabile. Inizia piccolo e sali finché le interruzioni scompaiono.

Perché le cuffie Bluetooth hanno una latenza così alta?

I codec audio Bluetooth introducono un ritardo di elaborazione considerevole per la compressione e la trasmissione wireless. Il codec SBC, standard sulla maggior parte dei dispositivi, aggiunge circa cento a centottanta millisecondi di latenza, con il valore esatto che dipende da codec, buffer del dispositivo e qualità della connessione (Bluetooth.com: A2DP v1.4). Anche il migliore aptX Low Latency raggiunge solo quaranta a ottanta millisecondi (Qualcomm: aptX Low Latency Whitepaper, 2014). Il ritardo è intrinseco al protocollo wireless: il codec deve comprimere, trasmettere e decomprimere ogni frame. Per ogni uso sensibile al timing — produzione musicale, gioco, montaggio video — cuffie o altoparlanti cablati sono la scelta pratica.

Articoli correlati