Latência de áudio: medindo atraso de microfone e alto-falante

Publicado em 2026-04-13 8 min de leitura

Resumo (TL;DR)

Gravar uma tomada de violão acústico pela minha antiga interface USB costumava parar em torno de 35 ms de latência de ida e volta nos fones de monitoramento — o bastante para que qualquer frase rítmica parecesse atravessar areia molhada. Trocar para uma MOTU M2 com um driver ASIO configurado direito trouxe isso para a faixa de 5 ms, e a mesma tomada foi imediatamente de “imprópria para tocar” para “natural”. O fenômeno não é um bug; é uma realidade física mensurável chamada latência de ida e volta (RTT). A RTT é a soma de cinco estágios: o sinal do microfone preenchendo um buffer de entrada, o software host processando esse buffer, o sinal processado preenchendo um buffer de saída, o DAC convertendo de volta para analógico, e o som final propagando-se pelo ar até o seu ouvido (cerca de 1 ms a cada 34 cm). A parte ajustável mora principalmente no tamanho do buffer e no modelo de driver; ASIO, WASAPI Exclusive, Core Audio e JACK cada um tem mínimos típicos e limites de plataforma diferentes. Este guia explica como esses componentes somam, por que a troca entre taxa de amostragem e tamanho do buffer não é tão intuitiva quanto parece, e como medir a latência real fim a fim com um cabo de loopback, um tom de teste e um editor de áudio — em vez de confiar nas alegações de “1 ms” do marketing.

Contexto e conceitos

Entre um microfone e um alto-falante, um computador faz mais do que a maioria das pessoas imagina. Um ADC amostra o sinal do microfone a uma taxa de amostragem escolhida (comumente 48 kHz) e coleta amostras em um buffer de entrada. Assim que o buffer enche — digamos, 128 amostras a 48 kHz, cerca de 2,67 ms de áudio — o driver entrega ao aplicativo.

O aplicativo (uma DAW, um cliente de comunicação, um navegador) processa o buffer, aplica efeitos ou codifica para transmissão em rede e escreve o resultado em um buffer de saída. Quando o buffer de saída enche, o DAC o converte em um sinal analógico que sai pela saída de fone ou de linha.

Depois há o mundo fora do computador. O som viaja a cerca de 343 m/s à temperatura ambiente, o que significa cerca de 1 ms por 34 cm. Fones de ouvido praticamente não adicionam nada disso; um monitor do outro lado da sala adiciona alguns milissegundos em cima de todo o resto. Um par de monitores a 1,7 m de distância da cadeira contribui com aproximadamente 5 ms de pura propagação — invisível na folha de especificações, mas presente nos seus ouvidos.

Então latência de ida e volta = buffer de entrada + processamento + buffer de saída + DAC + propagação. Com a taxa de amostragem fixa, buffers menores reduzem a latência mas elevam a carga de CPU, porque a thread de áudio precisa acordar mais frequentemente. Se o tamanho do buffer for especificado em amostras em vez de em tempo, aumentar a taxa de amostragem encurta o mesmo buffer de “N amostras” em milissegundos, mas taxas de amostragem maiores também elevam a vazão e estressam os drivers de forma diferente, então isso não é uma forma gratuita de reduzir o atraso.

O modelo de driver fica entre o aplicativo e o hardware de áudio e tem suas próprias características de latência. No Windows, os caminhos clássicos MME e DirectSound adicionam buffering substancial por compatibilidade; o WASAPI Shared é mais baixo, mas ainda mediado pelo mixer; WASAPI Exclusive e ASIO contornam boa parte dessa sobrecarga. O ASIO4ALL é um wrapper ASIO genérico que ajuda quando um driver ASIO do fabricante não está disponível, mas não substitui um driver ASIO de fabricante verdadeiro — a RTT medida no mesmo Focusrite Scarlett 2i2 3rd Gen tipicamente fica significativamente mais baixa com o driver oficial do que com ASIO4ALL em cima do WASAPI. No macOS, o Core Audio já é ajustado para baixa latência como padrão da plataforma. No Linux, as stacks JACK e PipeWire podem alcançar latência muito baixa uma vez configuradas, mas exigem agendamento de kernel em tempo real para serem consistentes.

Comparação e dados

CritérioASIOWASAPI ExclusiveCore AudioJACK
PlataformaPrincipalmente WindowsWindows apenasmacOS apenasCentrado em Linux, com ports cross-platform
Latência mínima típicaMuito baixa, comumente em poucos milissegundosBaixa quando usado em modo exclusivoBaixa e estável na casa dos poucos milissegundosMuito baixa quando bem configurada, com mais complexidade de setup
Modelo de compartilhamentoDepende do driver (tipicamente exclusivo)Compartilhado ou exclusivo; exclusivo é de menor latênciaModo compartilhado bem afinado é o padrãoBaseado em matriz de roteamento, multi-cliente

Números exatos em milissegundos dependem fortemente do hardware, driver e versão do SO, então em vez de confiar na linha de “latência de 1 ms” de uma página de produto, meça seu próprio sistema uma vez para estabelecer uma linha de base. Interfaces acessíveis como a MOTU M2 e a Focusrite Scarlett 2i2 3rd Gen conseguem alcançar ida e volta de um dígito de milissegundo quando emparelhadas com um driver ASIO ou Core Audio adequado, mas o mesmo hardware por um caminho WASAPI compartilhado do Windows ou embrulhado em ASIO4ALL tipicamente tem desempenho notavelmente pior. Sua RTT real é o resultado conjunto de três variáveis — interface, driver, tamanho do buffer — e assumir qualquer uma delas isoladamente raramente é preciso.

Cenários reais

Cenário 1 — Performance ao vivo e monitoramento in-ear. Uma cantora ouvindo a própria voz por monitores in-ear vai sentir um atraso de poucos milissegundos como um problema de tempo. O alvo aqui é RTT abaixo de 10 ms, o que geralmente exige tamanhos de buffer baixos, um driver de baixa latência (ASIO no Windows, Core Audio no macOS) e — onde possível — o recurso de monitoramento direto por hardware da interface, que contorna o caminho de software inteiramente para o sinal de monitoramento. O botão de monitor no painel frontal da MOTU M2 resolve isso em um giro, e o switch “Direct” da Scarlett 2i2 3rd Gen faz o mesmo.

Cenário 2 — Gravação de podcast. A menos que vários apresentadores estejam se monitorando ao vivo, 50 a 100 ms de RTT normalmente estão bem durante a sessão de gravação. A pós-produção alinha as faixas de qualquer maneira, e um buffer maior melhora a folga de CPU, o que por sua vez reduz o risco de dropouts em uma gravação longa. Otimizar para a menor latência aqui frequentemente atrapalha em vez de ajudar.

Cenário 3 — Videoconferência. Chamadas baseadas em WebRTC no navegador tipicamente operam numa faixa de aproximadamente 100 a 200 ms fim a fim por causa de rede, codificação e buffering de jitter em cima da latência local de áudio. Isso fica perto da fronteira onde a alternância de fala na conversa parece natural; adicionar fones Bluetooth com um codec antigo pode empurrar para além desse limiar, o que é por que participantes começam a falar por cima uns dos outros.

Cenário 4 — Colaboração musical online. Tentar tocar música sincronizada com um parceiro remoto pela internet é o lado implacável desse espectro. Além de aproximadamente 25 a 30 ms de atraso de uma via, manter um andamento estável vira difícil, e internet típica doméstica mais software de áudio de consumo regularmente aterrissa bem acima disso. Plataformas dedicadas de colaboração de baixa latência existem especificamente para cortar cada milissegundo possível, e mesmo assim geralmente exigem ethernet cabeada, ajuste cuidadoso de driver e proximidade física na espinha dorsal da internet. Reconhecer que uma stack de videochamada de consumo é a ferramenta errada para esse trabalho costuma ser o primeiro passo.

Equívocos comuns

“Áudio Bluetooth é sempre de alta latência.” Streaming A2DP clássico adiciona atraso significativo. Mas codecs mais novos como LE Audio (LC3) e aptX Low Latency trazem isso para baixo consideravelmente, o que é uma mudança de categoria na performance sentida. Dois fones que ambos dizem “Bluetooth” podem diferir dramaticamente dependendo do codec que eles e a fonte suportam. Para monitorar uma sessão de gravação, porém, com fio permanece a escolha mais segura.

“Áudio USB é sempre melhor que analógico.” Áudio USB bate o analógico onboard quando a interface tem um bom DAC, pré-amplificadores limpos e drivers estáveis. DACs USB baratos podem na verdade ser piores por causa de jitter, ruído e problemas de driver. “USB” sozinho não implica qualidade; a escolha dos componentes sim.

“Taxa de amostragem de 192 kHz é de menor latência.” Contra-intuitivo, mas importante: se o buffer é especificado em tempo (ms), aumentar a taxa de amostragem não reduz a latência física. Só quando o buffer é fixado em amostras é que uma taxa de amostragem maior significa menos milissegundos por buffer — ao custo de mais dados por segundo, mais CPU e mais estresse no driver. Baixa latência vem principalmente de buffers menores e um melhor modelo de driver, não de uma taxa de amostragem maior.

“Monitoramento por software e por hardware parecem iguais.” Não parecem. Monitoramento por software roteia o sinal do microfone pelo caminho da DAW — buffer de entrada, processamento de plugin, buffer de saída — e acumula RTT pelo caminho. Monitoramento por hardware em uma interface de áudio envia o sinal do microfone diretamente para a saída de fone dentro da interface, contornando o computador inteiramente para o caminho de monitoramento. O performer se ouve com latência efetivamente zero, enquanto o computador continua gravando a faixa para produção posterior. Muitos setups confundem os dois e culpam o tamanho do buffer por um atraso que o monitoramento por hardware eliminaria em uma única mudança de configuração.

Checklist

  1. Defina o alvo de RTT para o seu caso de uso. Performance ao vivo: abaixo de 10 ms; gravação: 50 a 100 ms está bem; conferência: 100 a 200 ms é realista.
  2. Escolha o modelo de driver. No Windows, ASIO ou WASAPI Exclusive; no macOS, Core Audio; no Linux, JACK ou PipeWire. Stacks padrão em modo compartilhado (MME, WASAPI compartilhado padrão) normalmente têm a maior latência.
  3. Reduza o tamanho do buffer incrementalmente até pouco antes de começarem os dropouts. Esse é o piso prático do seu sistema.
  4. Faça uma medição por loopback. Conecte a saída da interface à entrada com um cabo, toque um tom de teste e leia o atraso na forma de onda capturada em um editor de áudio.
  5. Combine a taxa de amostragem com a necessidade do projeto. 48 kHz é típico para vídeo; 44,1/48 kHz para música. Suba acima só com um motivo específico.
  6. Use o caminho de monitoramento com sabedoria. Onde possível, use o recurso de monitoramento direto da interface para os ouvidos do performer, o que torna a RTT de monitoramento efetivamente zero mesmo se o caminho de gravação tiver vários milissegundos de latência.

Ferramenta relacionada

A ferramenta de latência de áudio da Patrache Studio estima a latência de ida e volta no navegador, o que facilita obter uma leitura aproximada sem comprar hardware. Para o quadro mais amplo de “latência de entrada” em contexto de jogos, veja Teclado NKRO e latência de entrada para jogos. Se você está afinando um setup de videochamada em que o atraso de áudio afeta o sync A/V, combine este guia com Diagnóstico de webcam: taxa de quadros, resolução e iluminação para entender a latência do lado da câmera que se empilha em cima do áudio.

Referências

Ferramenta relacionada

diagno.patrache.studio/audio/latency/