Um teste de alto-falante informa sobre a latência de áudio?

Não. Um teste de alto-falante reproduz um tom e confirma que o som sai. Ele verifica se o caminho de saída está funcional, não quanto tempo o sinal leva para percorrer a cadeia de entrada e saída. Latência é uma medida de tempo, não um teste de funcionalidade, e os dois são independentes: um sistema pode passar em todas as verificações de reprodução e ainda apresentar latência catastrófica. Para medir a latência, você precisa de um teste de ida e volta que envie um impulso conhecido pela saída, capture o sinal de retorno na entrada e calcule a diferença entre transmissão e recepção.

O que exatamente é latência de ida e volta?

Latência de ida e volta, também chamada de atraso de ida e volta ou tempo de ida e volta, é o tempo total desde que um sinal entra no sistema pela entrada, passa por processamento do sistema operacional e de aplicações, e sai pela saída. Inclui o atraso do buffer de entrada, a conversão analógico-digital, o agendamento do sistema operacional, o processamento da aplicação, a conversão digital-analógica e o buffer de saída. Medida em milissegundos, é o caminho completo do microfone ao alto-falante. Note que medições no navegador capturam a ida e volta acústica pelo ar, enquanto o ASIO relata o caminho elétrico interno: não são o mesmo número.

Minha latência medida é de 80 milissegundos: isso é ruim para produção musical?

Para a maioria da produção musical, sim, é alta. Músicos que gravam acompanhados por trilha de apoio ou cliques preferem latência abaixo de quarenta milissegundos para tocarem em tempo sem um eco perceptível. Aos oitenta milissegundos, o atraso é claramente audível como um defasamento entre o que você toca e o que ouve, dificultando muito manter o tempo firme. Para gravações casuais ou podcasts, o atraso é perceptível, mas muitas vezes tolerável. Para monitoramento em tempo real durante uma sessão de gravação, oitenta milissegundos costumam ser impraticáveis. Lembre-se de que a tolerância individual varia conforme a experiência e o gênero.

Por que a latência medida no navegador é maior que em softwares de áudio profissionais?

Os navegadores são projetados para consistência entre plataformas e segurança de aplicações web, não para desempenho profissional de áudio. Softwares profissionais como Reaper e Ableton podem usar drivers ASIO no Windows para contornar a camada de mistura do sistema operacional e acessar o hardware diretamente, alcançando comumente latências de oito a quinze milissegundos. Os navegadores precisam passar pela camada compartilhada de áudio do sistema, o que adiciona sobrecarga de mistura e agendamento, sem acesso a modos exclusivos de baixa latência. O navegador mede o melhor que esse caminho compartilhado pode oferecer, inerentemente maior que um caminho direto via driver na maioria dos casos.

Quanto um driver ASIO reduz a latência?

No Windows, mudar do modo compartilhado padrão WASAPI para ASIO ou para o modo exclusivo WASAPI pode reduzir a latência de trinta a sessenta milissegundos para oito a quinze milissegundos. A redução exata depende da interface de áudio e da implementação do seu driver. O ASIO funciona dando à aplicação acesso direto aos buffers de hardware, contornando o mixer de áudio do Windows e a sobrecarga associada de buffering. Nem todas as placas de som suportam ASIO; áudio onboard de baixo custo geralmente não suporta. Para trabalho profissional no Windows, uma interface de áudio com suporte ASIO é uma das atualizações mais impactantes para a latência, mas avalie se seu fluxo de trabalho realmente exige isso antes de comprar.

Uma taxa de amostragem mais alta significa menor latência?

Não diretamente. A taxa de amostragem define quantas vezes por segundo o áudio é medido, o que afeta a resposta em frequência e a sobrecarga de processamento, mas não o atraso do buffer. O tamanho do buffer é o controle primário da latência: buffers menores significam menos tempo de espera para que os dados se acumulem antes de serem processados. Contudo, taxas mais altas aumentam a vazão necessária para o mesmo buffer, o que pode causar subescrita do buffer se o sistema não conseguir acompanhar. A abordagem prática é definir a taxa para corresponder ao seu fluxo, tipicamente quarenta e oito quilohertz, e depois minimizar o tamanho do buffer.

Como o tamanho do buffer afeta latência e estabilidade?

O tamanho do buffer define quantas amostras ficam em memória antes de serem processadas. Um buffer menor reduz a latência, mas deixa menos tempo para o sistema entregar o próximo bloco, aumentando o risco de subescrita: estalos, pops ou quedas audíveis. Um buffer maior é mais estável, mas adiciona latência. O ponto ideal depende do hardware: um computador rápido com uma boa interface de áudio pode usar buffers de sessenta e quatro ou cento e vinte e oito amostras com baixa latência e sem falhas. Um sistema mais lento pode precisar de quinhentos e doze ou mil amostras para permanecer estável.

Por que fones Bluetooth têm latência tão alta?

Os codecs de áudio Bluetooth introduzem atrasos significativos para compressão e transmissão sem fio. O codec SBC, usado por padrão na maioria dos dispositivos, adiciona cerca de cem a cento e oitenta milissegundos de latência, embora o valor exato dependa do codec, do buffering do dispositivo e da qualidade do enlace (Bluetooth.com: A2DP v1.4 (https://www.bluetooth.com/specifications/)). Mesmo o aptX Low Latency, de qualidade superior, alcança apenas quarenta a oitenta milissegundos (Qualcomm: aptX Low Latency Whitepaper, 2014 (https://www.qualcomm.com/products/aptx)). O atraso é inerente ao protocolo sem fio: o codec precisa comprimir, transmitir e descomprimir cada quadro. Para aplicações em que o tempo importa — produção musical, jogos, edição de vídeo — fones ou alto-falantes com fio são a opção prática para trabalhos sensíveis ao tempo.

Latência de Loopback: o que os testes de áudio não revelam

A maioria dos testes de áudio verifica se o som é reproduzido e se o microfone capta. Nenhum deles mede a latência de ida e volta: o tempo entre um sinal entrar no microfone e sair dos alto-falantes. Esse único número define se músicos conseguem gravar em tempo, se videoconferências soam naturais e se o áudio espacial em jogos soa preciso. Um sistema pode passar em todos as verificações de reprodução e ainda apresentar latência catastrófica, porque funcionalidade e tempo são eixos distintos. Este guia explica como medir a latência de ida e volta, o que os números significam e como reduzi-la.

Todo check de hardware começa da mesma forma. Ligue os alto-falantes novos, toque o tom de teste, confirme que o som saiu, avance. Ligue o microfone, fale, veja o medidor de nível subir, avance. Esses dois testes confirmam que seu caminho de saída funciona e que seu caminho de entrada funciona. Nenhum deles mede a pergunta que realmente decide se sua configuração de áudio consegue lidar com trabalho real: quanto tempo um som leva para ir do microfone, passar pelo computador e sair dos alto-falantes? Esse número é a latência de ida e volta, e ela determina em silêncio quais tarefas seu sistema consegue executar de verdade:

Gravar música. Tocar junto com um cliques ou trilha de apoio exige que seu próprio som retorne aos seus ouvidos quase imediatamente. Acima de aproximadamente quarenta milissegundos de ida e volta, seu tempo oscila, todas as tomadas soam lentas e nenhuma quantidade de prática resolve. Interfaces de áudio que compartilham um controlador USB com outros dispositivos também podem sofrer de concorrência de banda USB, o que adiciona picos de latência aos atrasos de buffer.
Manter conversações. Videoconferências só soam naturais quando o pipeline de áudio se mantém apertado. O atraso excessivo gera eco, fala sobreposta e o ritmo truncado de uma ligação por satélite.
Jogar com áudio espacial. O som posicional só funciona quando o áudio chega em sincronia com o que você vê. Quando o caminho de áudio fica para trás da tela, passos e tiros se desfazem da ação em tela. Seu teste de alto-falante e seu teste de microfone respondem “funciona?” O teste de latência de loopback responde “quão rápido?” Esta página explica o que é a latência de ida e volta, de onde ela vem e como trazê-la para baixo. Os valores aqui vêm de experiência geral em muitas configurações de hardware e software: uma configuração ASIO real em um Focusrite Scarlett 2i2 vai dar números diferentes de um codec Realtek onboard no Windows 11. Seus resultados variarão conforme sua interface, driver e configurações de buffer específicos.

O teste de tom não mede a latência

Um teste de alto-falante reproduz um tom, um varrido ou uma amostra musical pelo seu caminho de saída e confirma que o som emerge. É um check de funcionalidade com resultado pass/fail: o cabo está conectado, o driver está carregado, o volume não está mudo, o conversor digital-analógico está vivo. Se você consegue ouvir o tom, o caminho de saída funciona. É tudo o que o teste pode dizer. Um teste de microfone faz o mesmo para a direção de entrada. Ele captura o que você fala, exibe um medidor de nível e confirma que o microfone, o pré-amplificador e the conversor analógico-digital estão funcionando. Novamente, o resultado é pass ou fail. A medição de latência é uma espécie de teste completamente diferente. Em vez de perguntar se um sinal consegue atravessar um caminho, ela pergunta quanto tempo a travessia leva. O procedimento é simples: envie um sinal conhecido — um impulso, um clique, um breve pulso — pela saída, capture-o na entrada e calcule a diferença de tempo entre transmissão e recepção. Essa diferença é a latência de ida e volta, expressa em milissegundos. A distinção importa porque as duas medições são independentes. Um sistema pode passar em todos os testes de reprodução e ainda apresentar latência catastrófica. Alto-falantes Bluetooth são o exemplo clássico: reproduzem um tom com fidelidade, então o teste de alto-falante relata sucesso, enquanto o codec sem fio adiciona cem a cento e oitenta milissegundos de atraso que nenhum teste de reprodução percebe. Um tom que chega cento e cinquenta milissegundos atrasado ainda está, rigorosamente falando, sendo reproduzido. É por isso que a suposição comum — “meus alto-falantes soam bem, então meu sistema de áudio está bom” — se desfaz para qualquer coisa sensível ao tempo. Função e tempo são eixos separados. Antes de confiar na sua configuração para gravação, chamadas ou jogos, você precisa do número que os testes de reprodução são estruturalmente incapazes de produzir.

Observe o Preenchimento do Buffer

A latência de ida e volta não é um atraso único. É a soma de atrasos acumulados em cada etapa entre o captador do microfone e o cone do alto-falante. Compreender o caminho mostra exatamente onde seus milissegundos estão se escondendo:

Buffer de entrada. O conversor analógico-digital amostra continuamente, mas o sistema operacional entrega áudio em blocos. O driver espera um buffer completo antes de entregar dados à aplicação. A 48 kHz, um buffer de 128 amostras leva 2,7 milissegundos para se encher — esse é o tempo que seu áudio espera antes de alguém processá-lo. A maioria dos sistemas mantém dois ou três buffers em trânsito. Espere cerca de cinco a oito milissegundos antes da aplicação ver a primeira amostra.
Conversão analógico-digital. O conversor precisa de tempo para amostrar, quantizar e sincronizar o sinal. Em hardware de consumo isso costuma contribuir de um a três milissegundos; interfaces dedicadas fazem melhor.
Agendamento do sistema operacional. A engine de áudio acorda sua aplicação por um timer, e o despertar está sujeito ao agendamento normal de threads. Nos modos compartilhados, o sistema operacional também mistura seu fluxo com todas as demais fontes de áudio do sistema, adicionando sua própria passada de processamento. Esta etapa contribui de poucos milissegundos a vinte ou mais, dependendo da plataforma e da carga. É a etapa em que o Linux com PipeWire pode ultrapassar o Windows — e onde um ambiente desktop barulhento pode silenciosamente explodir sua latência.
Processamento da aplicação. O software do lado receptor — uma estação de áudio digital, uma cadeia de efeitos, um grafo de áudio do navegador — processa o bloco antes de encaminhá-lo. Pequeno, mas parte do total.
Conversão digital-analógica. O espelho da etapa dois, adicionando mais um a três milissegundos enquanto o sinal processado se torna uma tensão analógica.
Buffer de saída. As amostras processadas ficam no buffer de saída até o conversor estar pronto para reproduzi-las, repetindo a matemática de tamanho de buffer do lado de entrada. Adicione mais cinco a oito milissegundos em configurações típicas. Some as etapas e a latência de ida e volta em modo compartilhado costuma cair entre trinta e sessenta milissegundos em um computador comum — os valores medidos a seguir são exemplos ilustrativos de hardware específico, não especificações universais. Em testes informais em um notebook Windows 11 padrão com codec Realtek ALC897 onboard em buffer de 128 amostras, medições em modo compartilhado foram observadas perto do extremo superior dessa faixa. Com um Behringer U-Phoria UM2 via ASIO4ALL no mesmo hardware, a medição caiu perto de quinze milissegundos. Estas são observações de máquina única sem condições controladas; servem como pontos de referência para o típico intervalo entre caminhos compartilhado e ASIO, não como valores garantidos para seu hardware. Nenhum driver remove o tempo de conversão — mas a sobrecarga de buffering e agendamento, que dominam o total, diminui dramaticamente.

Um número, duas definições

Software de áudio raramente cita um único número. Abra as configurações de uma aplicação profissional e você normalmente verá dois: latência de entrada, o tempo do microfone até a aplicação, e latência de saída, o tempo da aplicação até os alto-falantes. Drivers como o ASIO relatam ambos separadamente, e material de marketing costuma citar o valor que parece melhor. A latência de ida e volta é a soma dos dois, mais o tempo de processamento da aplicação. Se um sistema cita vinte milissegundos em um único sentido, a ida e volta é aproximadamente quarenta milissegundos. Um usuário que lê “20 ms de latência” e assume que esse é o atraso que ouvirá está errado por um fator de dois — e o erro é comum porque as cifras de um único sentido são as impressas nas fichas técnicas. A distinção importa porque o que você percebe é sempre a ida e volta. Quando um músico monitora sua própria voz ou instrumento, o som precisa sair do microfone, passar pelo sistema e retornar aos fones antes dele ouvi-lo. Esse é o caminho completo. Uma cifra de um único sentido descreve apenas metade da viagem. Para manter a discussão consistente, todos os números aqui se referem à latência de ida e volta. Ao comparar sua medição contra uma especificação de produto ou um benchmark, verifique sempre que ambos os números descrevem o mesmo tipo de viagem. Comparar uma medição de ida e volta contra uma especificação de um único sentido faz seu sistema parecer o dobro do lento que realmente é.

O Sistema Operacional Decide Antes de Você

O mesmo microfone, os mesmos alto-falantes e o mesmo cabo produzem latências drasticamente diferentes em sistemas operacionais diferentes, porque cada plataforma encaminha áudio por uma pilha de software diferente. A pilha decide quanto buffering e sobrecarga de agendamento são adicionados ao tempo inelutável de conversão.

Windows: modo compartilhado, modo exclusivo e ASIO

O Windows oferece três formas de alcançar o hardware, cada uma com um perfil de latência diferente:

Modo compartilhado WASAPI é o caminho padrão usado por cada aplicação, a menos que ela peça algo diferente (Microsoft Learn: WASAPI Shared Mode, 2023). Todo o áudio é misturado e entregue com buffering conservador. Intervalos de latência de ida e volta comumente observados variam de trinta e dois a sessenta e quatro milissegundos em sistemas típicos, dependendo do buffer e da carga — estes são intervalos de experiência comum, não valores garantidos. Web Audio, WebRTC e reprodução de mídia atravessam caminhos levemente diferentes, mas todos começam nesse mixer compartilhado.
Modo exclusivo WASAPI ou ASIO contorna o mixer e entrega a uma aplicação acesso direto ao dispositivo, reduzindo comumente a latência para cerca de dez milissegundos em hardware típico (Microsoft Learn: WASAPI Exclusive Mode, 2023). Está disponível a aplicações nativas que o solicitam; navegadores não podem.
ASIO é um protocolo de driver que contorna toda a pilha de áudio do Windows e comunica diretamente com o hardware da interface (Steinberg: ASIO Host and Driver Guide v2.3, 2021). Com uma interface capaz, o ASIO alcança comumente oito a quinze milissegundos, embora os números exatos dependam da interface específica, da versão do driver e da configuração do buffer. Navegadores não podem usá-lo.

macOS: Core Audio

O framework Core Audio da Apple é bem otimizado e aplicações nativas alcançam rotineiramente oito a vinte milissegundos de ida e volta com configurações razoáveis de buffer. O caminho compartilhado é eficiente, então até a latência medida no navegador no macOS costuma ser melhor que no Windows. Ainda assim fica acima do mínimo nativo, porque o navegador não consegue acessar o dispositivo de forma exclusiva nem afinar o buffer às suas próprias necessidades.

Linux: ALSA, PulseAudio e PipeWire

A latência no Linux é um alvo móvel. O ALSA, a interface de driver de baixo nível, é rápida, mas específico por aplicação. O PulseAudio historicamente adicionava sobrecarga de buffering perceptível. O PipeWire, a substituição moderna, é projetado para áudio de baixa latência e pode igualar ou superar as outras plataformas quando configurado corretamente, mas os resultados variam amplamente com a distribuição e a configuração. Na maioria das configurações, o navegador fica confinado ao caminho compartilhado. Não consegue solicitar modos exclusivos, não carrega drivers ASIO e não eleva a prioridade de sua thread de áudio. A latência de áudio no navegador é, portanto, tipicamente mais próxima do teto em modo compartilhado da sua plataforma — o melhor que o caminho cooperativo pode entregar em configurações padrão — enquanto software profissional nativo é construído para escapar desse teto quando o hardware e o driver permitem.

O que 60 milissegundos realmente significam

Uma cifra bruta de milissegundos não significa nada até você mapeá-la contra o que pretende fazer. As fronteiras abaixo são orientações gerais, não padrões de certificação profissional; a adequação real depende da sua tarefa específica, da configuração de monitoramento e do ambiente de escuta. Quatro zonas cobrem o alcance prático:

Abaixo de 20 ms — excelente. A produção musical profissional fica confortável aqui. Músicos podem gravar junto a cliques, se monitorar com efeitos e tocar em tempo porque o caminho de retorno é efetivamente instantâneo. O áudio espacial em jogos fica travado nas imagens.
20–60 ms — aceitável para a maioria dos usos. Podcasts, videoconferências, jogos gerais e gravações casuais funcionam bem. Gravações musicals apertadas começam a sofrer perto do topo dessa faixa: os músicos sentem o retorno do som deles arrastando levemente, e trabalho de precisão fica visivelmente mais difícil acima de aproximadamente quarenta milissegundos.
60–120 ms — problemático para produção, aceitável para uso casual. Karaoke, bate-papo por voz e escuta estão bem. Gravar junto a uma trilha de apoio fica genuinamente difícil, e nos jogos o áudio começa a se desprender da ação, destruindo as pistas posicionais nas quais o áudio espacial depende.
Acima de 120 ms — ruim. Trabalho sensível ao tempo é efetivamente impossível. Chamadas desenvolvem eco audível, performances parecem desconectadas e áudio espacial soa errado mesmo em uso casual. Esta zona é o lar natural do áudio Bluetooth e de sistemas em modo compartilhado mal configurados. As fronteiras das zonas são julgamentos, mas a forma é confiável: produção precisa dos números mais baixos, conversa tolera mais, e escuta casual tolera o máximo. Sua medição de ida e volta coloca seu sistema em exatamente uma zona, e essa posição diz quais usos pretendidos serão agradáveis e quais vão lutar contra você. Mantenha o número por perto — ele é o ponto de referência para cada otimização na próxima seção.

Três alavancas: taxa de amostragem, buffer, driver

Três controles determinam onde seu atraso se situa no caminho, e eles não são iguais em efeito. A taxa de amostragem define a vazão do pipeline — quantas vezes por segundo o áudio é medido — e não o atraso diretamente. Ela interage com o timing do buffer, porque um buffer é medido em amostras: 128 amostras levam 2,9 milissegundos a 44,1 kHz, mas apenas 1,3 milissegundos a 96 kHz, então o mesmo tamanho de buffer se traduz em durações diferentes em taxas distintas. O problema é que uma taxa mais alta exige mais processamento por segundo, o que frequentemente obriga você a aumentar o buffer de volta para manter a estabilidade, cancelando o ganho. Perseguir 96 ou 192 kHz geralmente força um buffer maior para manter o fluxo estável, o que pode cancelar o ganho teórico ou deixar as coisas mais lentas. Trate a taxa de amostragem como uma configuração de fluxo de trabalho, tipicamente 48 kHz, não como o controle primário de latência. 48 kHz se tornou o padrão de fato para áudio sincronizado a vídeo porque mapeia limpa para taxas de quadro de vídeo de 24, 25 e 30 fps, motivo pelo qual o pipeline profissional de áudio e vídeo padrão usa esse valor. O tamanho do buffer é a alavanca primária de latência. Ele determina quanto áudio se acumula antes do sistema processá-lo, e ele aparece duas vezes na ida e volta — uma vez no lado de entrada e uma vez no lado de saída. Cortar o buffer pela metade corta essa porção do atraso, mas também corta pela metade o tempo que o sistema tem para entregar cada bloco, aumentando o risco de subescrita do buffer: estalos, pops e quedas. A matriz prática a 48 kHz é assim:

64 amostras — aproximadamente 8–12 ms de ida e volta em hardware capaz com ASIO ou modo exclusivo. Interfaces econômicas costumam produzir estalos nesse tamanho.
128 amostras — aproximadamente 12–20 ms. Um ponto doce ASIO comum para produção.
256 amostras — aproximadamente 20–35 ms. Muitas vezes o tamanho mínimo estável em modo compartilhado.
512 amostras — aproximatamente 35–60 ms. Seguro, mas visivelmente lento.
1024 amostras — aproximadamente 60–100 ms. Apenas para streaming ou reprodução onde a latência é irrelevante. O driver define o piso. ASIO e modo exclusivo permitem buffers de 32 a 128 amostras; o modo compartilhado tem um piso mais alto; codecs Bluetooth adicionam cem milissegundos ou mais antes dos buffers serem considerados. Nenhum ajuste de buffer supera o mínimo do driver, motivo pelo qual o driver é a primeira alavanca, não a última.

O Navegador Não é um DAW

Um navegador pode estimar a latência de ida e volta usando a Web Audio API (MDN: Web Audio API, 2024), que agenda um impulso pela saída e captura o sinal que chega na entrada do microfone. Uma medição típica de loopback Web Audio em um notebook em modo compartilhado costuma reportar 55–70 ms — várias vezes o valor do ASIO — um intervalo que ilustra o imposto de caminho compartilhado do navegador. O tempo medido inclui o caminho acústico pelo ar, os transdutores de alto-falante e microfone, o processamento de cancelamento de eco da sala e toda a pilha de áudio do sistema. Isso é chamado de atraso acústico de ida e volta, e é a cifra relevante para chamadas no navegador, karaoke e jogos no navegador, mas não equivale à latência de ida e volta ASIO que o software profissional mede. Tenha em mente que essa medição exige um caminho acústico real entre alto-falante e microfone; controle automático de ganho, supressão de ruído e cancelamento de eco podem alterar a forma do impulso, enquanto distância do microfone, reflexões da sala e configurações de volume afetam o resultado. O que o navegador não consegue fazer é alcançar o melhor caso do hardware. Ele deve usar o caminho compartilhado de áudio do sistema operacional, não consegue acessar o dispositivo de forma exclusiva, não carrega drivers ASIO e não controla seu próprio buffer ou prioridade de thread. A medição reflete, portanto, o teto em modo compartilhado da sua plataforma, não o mínimo verdadeiro do hardware. Esse teto é exatamente o número certo para trabalho no navegador. Chamadas web, jogos no navegador, karaoke web e tudo que roda dentro de uma aba compartilham o caminho de áudio do navegador no nível do sistema operacional, embora Web Audio, WebRTC e reprodução de mídia diferem em detalhes. Se o número medido no navegador for bom, todos os casos de uso no navegador sentirão-se bons. Se for ruim, software nativo ainda pode salvá-lo — mas o navegador geralmente será mais lento que software nativo no mesmo hardware e configuração.

Seis maneiras de reduzir a latência

Trabalhe o problema na ordem de impacto e pare assim que seu número cair em uma zona que você possa tolerar:

Corrija primeiro o modo do driver. No Windows, instale o driver ASIO da sua interface de áudio ou mude para o modo exclusivo WASAPI. É a maior alavanca de impacto e é gratuita.
Reduza o tamanho do buffer. Diminua de 512 para 256, para 128, para 64 amostras, testando cada configuração, até ouvir estalos ou pops. Depois, volte um nível ao tamanho maior que permanece limpo.
Verifique a taxa de amostragem. Use 48 kHz para música e vídeo. Perseguir 96 kHz ou 192 kHz geralmente força um buffer maior e acaba mais lento.
Feche aplicativos concorrentes. Streaming, captura e abas do navegador ocupadas roubam CPU da thread de áudio e causam subescrita em buffers pequenos.
Considere uma interface de áudio. Hardware dedicado traz conversores melhores, drivers ASIO adequados e tamanhos de buffer que áudio onboard não alcança.
Prefira conexões com fio. Para qualquer coisa sensível ao tempo, fones com fio superam o Bluetooth em cem milissegundos ou mais, independentemente de todas as demais configurações. Cada passo se acumula. Passar de modo compartilhado em 512 amostras para ASIO em 128 amostras costuma deslocar um sistema de cinquenta para abaixo de vinte milissegundos — a diferença entre impraticável e profissional.

Conclusão

Um teste de reprodução confirma que seus alto-falantes funcionam. Um teste de loopback confirma que eles funcionam em tempo — e essas são perguntas diferentes com respostas diferentes. Execute o teste de alto-falante para validar o caminho de saída e o teste de microfone para validar o caminho de entrada. Observe que este site atualmente não oferece uma ferramenta dedicada de medição de latência de loopback; a abordagem Web Audio API descrita acima requer uma implementação separada ou configuração no console do navegador. Use-a para aprender o atraso acústico de ida e volta que define se gravação, conversa e áudio espacial soam naturais na sua máquina. Meça uma vez e guarde o resultado. Abaixo de vinte milissegundos significa timing de nível profissional. De vinte a sessenta cobre a maioria do trabalho cotidiano. Acima de cento e vinte, toda tarefa sensível ao tempo vai lutar contra você, e a correção geralmente começa pelo driver, não pelo hardware. Se você nunca mediu o número, está adivinhando sobre cada tarefa de áudio que depende de timing.