O estalo que não é culpa da CPU: como achar o driver que trava seu áudioThe crackle that is not the CPU's fault: finding the driver that stalls your audio
Foto: DmitroCzegovets · CC BY
Tem um tipo de estalo que resiste a tudo que você tentou. O medidor da DAW está tranquilo, você já subiu o buffer, já fechou o navegador, já desligou plugin, e o barulho continua aparecendo em intervalos, do nada, às vezes exatamente quando você mexe o mouse ou quando alguém entra numa chamada de vídeo na casa.
Esse estalo não é falta de processamento. É outra coisa, tem nome, e o melhor de tudo, dá pra descobrir o culpado exato em dez minutos.
O que está acontecendo
O sistema precisa atender interrupções o tempo todo: a placa de rede recebeu um pacote, o disco terminou uma leitura, o mouse se moveu. Quando isso acontece, o driver responsável é chamado, faz o trabalho dele, e devolve o controle.
O acordo implícito é que ele devolva rápido. Um driver bem escrito ocupa a máquina por alguns microssegundos e sai.
Quando um driver mal comportado segura o controle por tempo demais, todo o resto espera. Inclusive a thread de áudio, que tem prazo. Se ela não conseguir a vez dentro da janela do buffer, o bloco de áudio não fica pronto a tempo, e o que sai da placa é um buraco.
É por isso que o medidor da DAW não denuncia nada. A CPU não está ocupada, ela está indisponível. São coisas diferentes, e o medidor só mostra a primeira.
O nome disso no Windows é DPC, que significa chamada de procedimento adiada. Você não precisa decorar a sigla, precisa saber que ela existe pra parar de procurar no lugar errado.
Como saber se é o seu caso
Alguns sinais apontam pra cá com bastante confiança:
- O estalo acontece com a CPU baixa.
- Aumentar o buffer melhora pouco, ou só melhora em valores absurdos que inviabilizam gravar.
- O estalo vem em rajadas, com alguma regularidade, em vez de acompanhar a densidade da música.
- Ele aparece junto de eventos do sistema: mexer o mouse, conectar um dispositivo, atividade de rede, a máquina acordando de uma economia de energia.
Se pelo menos dois desses batem, pare de otimizar a sessão. O problema não está nela.
A medição, que é a parte fácil
Existe uma ferramenta gratuita bem conhecida no meio, o LatencyMon, feita justamente pra isso. Ela fica escutando o sistema e mede quanto tempo cada driver segura a máquina.
O procedimento que funciona:
1. Feche o que não for necessário, mas deixe a máquina no estado normal de trabalho. Se você produz com o Wi-Fi ligado, deixe ligado. O objetivo é reproduzir a condição em que o estalo aparece, não uma condição de laboratório.
2. Deixe rodando por uns dez minutos, e use a máquina normalmente nesse tempo.
3. Olhe a aba de drivers, ordenada pelo maior tempo de execução.
O que interessa é o maior tempo medido, não a média. Um driver que se comporta bem 99 por cento do tempo e trava por 4 milissegundos uma vez por minuto produz exatamente um estalo por minuto.
Como referência grosseira: valores na casa de algumas centenas de microssegundos são confortáveis. Passando de um milissegundo, você já está no território onde buffer pequeno começa a falhar. Vários milissegundos explicam estalo até em buffer grande.
Os suspeitos de sempre
Na prática, a lista de culpados é curta e se repete:
- Rede sem fio. É o campeão, com folga. Placa Wi-Fi com driver ruim, ou com economia de energia agressiva, é a causa mais comum de todas.
- Vídeo. Driver de placa de vídeo, principalmente quando há duas telas com taxas de atualização diferentes.
- Gerenciamento de energia do processador. A máquina tentando baixar consumo bem na hora em que o áudio precisa de resposta.
- Controladores USB. Que conversa direto com o problema do hub, se você já leu sobre isso aqui.
- Bluetooth, que às vezes é o mesmo módulo físico do Wi-Fi.
- Controladora de armazenamento, com menos frequência.
Uma armadilha de leitura: a ferramenta costuma apontar um arquivo do próprio Windows, como o da camada de rede. Isso não significa que o Windows é o culpado. Aquela camada é uma via por onde o driver do fabricante passa. O culpado é o driver que está por baixo, quase sempre o da sua placa específica.
O que fazer com o nome que apareceu
Atualize o driver, e se não melhorar, volte pra uma versão anterior. Mais novo nem sempre é melhor, e regressão em driver é comum. Vale testar as duas direções.
Desligue a economia de energia daquele dispositivo. Nas propriedades do adaptador, existe uma opção que autoriza o Windows a desligá-lo pra poupar energia. Desmarcar isso resolve uma parte grande dos casos de rede.
Desligue o que você não usa enquanto produz. Se o Wi-Fi é o culpado e você consegue trabalhar no cabo, o problema acaba ali. Bluetooth idem.
Plano de alto desempenho. Impede o processador de ficar mudando de estado no meio da sessão.
Se for placa interna, experimente outro slot. Compartilhamento de linha entre slots existe e produz esse tipo de sintoma.
O que não resolve
Vale saber, porque poupa dinheiro e evita estrago.
Trocar de processador não resolve. Um driver que segura a máquina por três milissegundos vai segurar exatamente igual num processador duas vezes mais rápido. Ele não está calculando, está bloqueando.
Buffer maior não resolve sempre. Se a travada é maior que a janela, nenhum buffer razoável salva.
Script de otimização não resolve, e pode piorar. Aqueles pacotes que desligam dezenas de serviços de uma vez raramente tocam no driver que está causando o problema, e deixam a máquina num estado que ninguém sabe reverter. Você já tem o nome do culpado, trate ele.
Por que isso vale o seu tempo
A maioria dos guias de otimização manda desligar coisas no escuro, na esperança de acertar. Medir primeiro inverte a lógica: você descobre o nome do driver, mexe só nele, e sabe se funcionou.
E na maior parte das vezes o resultado é o mesmo: era a placa de rede.
There is a kind of crackle that resists everything you tried. The DAW meter is relaxed, you already raised the buffer, closed the browser, disabled plugins, and the noise keeps showing up at intervals, out of nowhere, sometimes exactly when you move the mouse or when someone in the house joins a video call.
That crackle is not a lack of processing power. It is something else, it has a name, and best of all, you can find the exact culprit in ten minutes.
What is actually happening
The system has to service interrupts constantly: the network card received a packet, the disk finished a read, the mouse moved. When that happens, the responsible driver is called, does its work, and hands control back.
The implicit agreement is that it hands back fast. A well written driver occupies the machine for a few microseconds and leaves.
When a badly behaved driver holds control too long, everything else waits. Including the audio thread, which has a deadline. If it does not get its turn inside the buffer window, the audio block is not ready in time, and what leaves the card is a hole.
That is why the DAW meter reports nothing. The CPU is not busy, it is unavailable. Different things, and the meter only shows the first.
The Windows name for this is DPC, meaning deferred procedure call. You do not need to memorise the acronym, you need to know it exists so you stop looking in the wrong place.
How to know if this is your case
A few signs point here with reasonable confidence:
- The crackle happens with low CPU.
- Raising the buffer helps little, or only helps at absurd values that make recording impossible.
- The crackle comes in bursts, with some regularity, rather than following the density of the music.
- It shows up alongside system events: moving the mouse, connecting a device, network activity, the machine waking from a power saving state.
If at least two of those match, stop optimising the session. The problem is not in it.
The measurement, which is the easy part
There is a well known free tool for exactly this, LatencyMon. It listens to the system and measures how long each driver holds the machine.
The procedure that works:
1. Close what is unnecessary, but leave the machine in its normal working state. If you produce with Wi-Fi on, leave it on. The goal is to reproduce the condition where the crackle appears, not a laboratory condition.
2. Let it run for about ten minutes, and use the machine normally during that time.
3. Look at the drivers tab, sorted by highest execution time.
What matters is the highest measured time, not the average. A driver that behaves 99 percent of the time and stalls for 4 milliseconds once a minute produces exactly one crackle per minute.
As a rough reference: values in the low hundreds of microseconds are comfortable. Past one millisecond you are in the territory where small buffers start failing. Several milliseconds explain crackles even at large buffers.
The usual suspects
In practice the list of culprits is short and repetitive:
- Wireless networking. The champion, by a wide margin. A Wi-Fi card with a poor driver, or with aggressive power saving, is the single most common cause.
- Video. Graphics drivers, especially with two displays running different refresh rates.
- Processor power management. The machine trying to cut consumption right when audio needs an instant answer.
- USB controllers. Which connects directly to the hub problem, if you have read about that here.
- Bluetooth, which is sometimes the same physical module as the Wi-Fi.
- Storage controllers, less frequently.
A reading trap: the tool often points at a Windows system file, such as the networking layer. That does not mean Windows is the culprit. That layer is a road the vendor driver travels on. The culprit is the driver underneath, almost always the one for your specific card.
What to do with the name that showed up
Update the driver, and if that does not help, roll back to an earlier version. Newer is not always better, and driver regressions are common. Worth testing both directions.
Turn off power saving for that device. In the adapter properties there is an option allowing Windows to switch it off to save power. Unchecking that resolves a large share of network cases.
Turn off what you do not use while producing. If Wi-Fi is the culprit and you can work on a cable, the problem ends there. Same for Bluetooth.
High performance power plan. Stops the processor from changing states mid session.
If it is an internal card, try another slot. Lane sharing between slots exists and produces exactly this symptom.
What does not solve it
Worth knowing, because it saves money and avoids damage.
Changing processor does not solve it. A driver that holds the machine for three milliseconds will hold it exactly the same on a processor twice as fast. It is not calculating, it is blocking.
A bigger buffer does not always solve it. If the stall is longer than the window, no reasonable buffer saves you.
Optimisation scripts do not solve it, and can make things worse. Those packages that disable dozens of services at once rarely touch the driver causing the problem, and leave the machine in a state nobody knows how to reverse. You already have the culprit's name, deal with that one.
Why this is worth your time
Most optimisation guides tell you to disable things in the dark, hoping to hit something. Measuring first inverts the logic: you learn the driver's name, touch only that, and know whether it worked.
And most of the time the answer is the same: it was the network card.
Plugins que você enxergaPlugins you can see
Conheça o PRISMA e o catálogo Ventura Audio.Meet PRISMA and the Ventura Audio catalog.
IR PARA A LOJAGO TO STORE
