CPU pra DAW: por que mais núcleo não reduz latência, e o que reduzCPU for your DAW: why more cores don't reduce latency, and what does
Existe uma compra que quase todo produtor faz uma vez: troca o processador por um com muito mais núcleos, esperando poder monitorar com buffer baixo sem estalo. Liga tudo, baixa o buffer pra 64, e o estalo continua exatamente onde estava.
Não houve defeito, nem propaganda enganosa. O que houve é que núcleo e latência não são o mesmo problema, e o dinheiro foi pra resolver o problema que você não tinha.
Latência não é velocidade, é tamanho de bloco
A DAW não processa áudio amostra por amostra. Ela junta um bloco, processa o bloco inteiro, entrega, e vai buscar o próximo. Esse bloco é o buffer.
A conta é direta, e não tem CPU nela:
buffer dividido pela taxa de amostragem
Um buffer de 128 amostras a 48 kHz dá 128 dividido por 48000, ou seja, 2,67 ms. Esse é o atraso de um sentido. Na prática você sente a ida e a volta: o sinal entra, é processado, e sai. Some o buffer de entrada, o de saída, a conversão AD e DA da interface e o transporte USB, e um 128 a 48 kHz costuma aterrissar entre 7 e 10 ms de latência total.
Repare no que não apareceu nessa conta: o processador. Ele não encurta a janela. A janela é definida pelo buffer que você escolheu. O que o processador decide é outra coisa, se ele consegue terminar o trabalho dentro daquela janela. Se conseguir, você ouve áudio limpo. Se não conseguir, você ouve estalo. Não existe meio termo, e não existe estalo "um pouco menor" porque a CPU é mais rápida.
O que o núcleo extra faz de verdade
A DAW distribui trabalho entre threads, e cada thread vai parar num núcleo. Mais núcleo significa mais coisa acontecendo ao mesmo tempo: mais pistas, mais instrumentos virtuais, mais plugins simultâneos antes de a máquina engasgar.
Só que existe um limite que núcleo nenhum resolve. Uma cadeia em série não se divide. Se uma pista tem oito plugins um atrás do outro, o segundo depende da saída do primeiro, o terceiro depende do segundo, e assim por diante. Isso roda numa thread só, num núcleo só. Ter mais quinze núcleos parados ao lado não acelera nada.
O caso clássico é o barramento máster. Tudo converge pra lá, e ali é uma cadeia única. Um limitador pesado, uma emulação de fita e um EQ linear no máster formam uma fila que um núcleo precisa vencer sozinho, dentro da janela de 2,67 ms. É por isso que uma sessão com poucas pistas e um máster carregado pode estalar mais que uma sessão com sessenta pistas leves.
Resumindo o que cada coisa governa:
- Desempenho de um núcleo só define o piso, ou seja, qual a cadeia mais pesada que cabe na janela.
- Quantidade de núcleos define o teto, ou seja, quantas cadeias você consegue ter ao mesmo tempo.
O que realmente reduz latência
Buffer menor. É a alavanca direta, e a única que mexe no número. O preço é folga de CPU, então ela só funciona até onde a máquina aguenta.
Taxa de amostragem maior. Um buffer de 128 a 96 kHz dá 1,33 ms, metade do mesmo buffer a 48 kHz. Você comprou latência com processamento, porque a 96 kHz a máquina faz o dobro de contas por segundo. É uma troca legítima quando sobra CPU e falta latência.
Driver certo. No Windows, ASIO fala direto com a interface. As camadas genéricas do sistema empilham buffers próprios por cima e jogam a latência pra dezenas de milissegundos. No Mac o Core Audio já é essa camada direta, e é por isso que lá o assunto quase não aparece.
Tirar lookahead do caminho de monitoramento. Limitador com lookahead, EQ de fase linear e oversampling pesado introduzem atraso próprio. A DAW compensa isso atrasando todo o resto, que é o certo pra alinhar a mixagem, mas significa que aquele plugin no máster está adicionando latência a tudo que você monitora. Na hora de gravar, deixe essa cadeia desligada.
Monitoramento direto na interface. A interface manda o sinal de entrada pro fone antes de ele entrar no computador. A latência vira zero porque o computador saiu do caminho. Você perde os efeitos, mas ganha a única latência que não tem discussão.
O gargalo que nem é a CPU
Vale conhecer dois vilões que produzem exatamente o mesmo sintoma, e que trocar de processador não resolve.
DPC. Um driver mal comportado, quase sempre de rede, de vídeo ou de gerenciamento de energia, segura o sistema por tempo demais durante uma interrupção. O áudio perde a janela e estala, mesmo com a CPU em 15 por cento. Existe ferramenta gratuita pra medir isso e apontar o driver culpado, e é o primeiro lugar pra olhar quando o estalo não faz sentido com o uso mostrado no medidor da DAW.
Economia de energia. Se o plano de energia deixa o processador baixar de frequência ou estacionar núcleos, uma sessão leve vira sessão instável, porque a máquina decide descansar justamente quando o áudio precisa de resposta imediata. Plano de alto desempenho enquanto produz.
Então, como escolher
Se o seu trabalho é gravar com buffer baixo, tocando junto com a sessão, priorize o desempenho de um núcleo só. É ele que decide se a sua cadeia mais pesada cabe na janela.
Se o seu trabalho é mixar sessão grande, com muitas pistas e muito plugin, priorize quantidade de núcleos e memória. Ali você trabalha com buffer alto de propósito, e latência nem é assunto.
E se você está no meio, que é onde quase todo mundo está, a verdade desconfortável é que provavelmente nenhum dos dois é o seu limite. Antes de trocar de máquina, meça o DPC, confira o plano de energia e olhe o que está pendurado no máster. Sai bem mais barato.
There is one upgrade almost every producer makes once: swap the processor for one with far more cores, expecting to monitor at a low buffer without crackling. Everything gets plugged in, the buffer drops to 64, and the crackle sits exactly where it was.
Nothing broke, and nobody lied in the ad copy. Cores and latency are simply not the same problem, and the money went to solve the one you did not have.
Latency is not speed, it is block size
A DAW does not process audio one sample at a time. It gathers a block, processes the whole block, delivers it, and goes for the next one. That block is the buffer.
The math is direct, and the CPU is not in it:
buffer divided by sample rate
A 128 sample buffer at 48 kHz gives 128 divided by 48000, which is 2.67 ms. That is one direction. What you actually feel is the trip out and back: signal in, processed, signal out. Add the input buffer, the output buffer, the interface AD and DA conversion and USB transport, and 128 at 48 kHz usually lands between 7 and 10 ms of total latency.
Notice what never showed up in that math: the processor. It does not shrink the window. The window is set by the buffer you chose. What the processor decides is something else, whether it can finish the work inside that window. If it can, you hear clean audio. If it cannot, you hear a crackle. There is no middle ground, and no such thing as a smaller crackle because the CPU is faster.
What the extra cores actually do
A DAW spreads work across threads, and each thread lands on a core. More cores means more happening at once: more tracks, more virtual instruments, more simultaneous plugins before the machine chokes.
But there is a limit no core count solves. A serial chain cannot be split. If a track has eight plugins in a row, the second depends on the output of the first, the third depends on the second, and so on. That runs on one thread, on one core. Fifteen idle cores sitting next to it speed up nothing.
The classic case is the master bus. Everything converges there, and it is a single chain. A heavy limiter, a tape emulation and a linear phase EQ on the master form a queue that one core has to clear alone, inside that 2.67 ms window. That is why a session with few tracks and a loaded master can crackle more than a session with sixty light ones.
What each thing governs:
- Single core performance sets the floor, meaning the heaviest chain that fits in the window.
- Core count sets the ceiling, meaning how many chains you can run at once.
What actually reduces latency
A smaller buffer. The direct lever, and the only one that moves the number. The price is CPU headroom, so it works only as far as the machine holds.
A higher sample rate. A 128 buffer at 96 kHz gives 1.33 ms, half of the same buffer at 48 kHz. You bought latency with processing, because at 96 kHz the machine does twice the math per second. A fair trade when CPU is plentiful and latency is not.
The right driver. On Windows, ASIO talks straight to the interface. The generic system layers stack their own buffers on top and push latency into the tens of milliseconds. On Mac, Core Audio already is that direct layer, which is why the subject barely comes up there.
Getting lookahead out of the monitoring path. Lookahead limiters, linear phase EQ and heavy oversampling introduce delay of their own. The DAW compensates by delaying everything else, which is correct for lining up a mix, but it means that plugin on the master is adding latency to everything you monitor. When tracking, switch that chain off.
Direct monitoring on the interface. The interface sends the input signal to your headphones before it ever reaches the computer. Latency becomes zero because the computer left the path. You lose the effects, and you gain the one latency figure nobody argues with.
The bottleneck that is not even the CPU
Two villains produce this exact symptom, and a new processor fixes neither.
DPC. A badly behaved driver, usually network, video or power management, holds the system too long during an interrupt. Audio misses its window and crackles, even with the CPU at 15 percent. There are free tools that measure this and name the guilty driver, and it is the first place to look when the crackle makes no sense against the DAW meter.
Power saving. If the power plan lets the processor drop frequency or park cores, a light session becomes an unstable one, because the machine decides to rest exactly when audio needs an instant answer. High performance plan while you work.
So how do you choose
If your work is tracking at a low buffer, playing along with the session, prioritise single core performance. That is what decides whether your heaviest chain fits the window.
If your work is mixing large sessions, many tracks and many plugins, prioritise core count and memory. There you run a high buffer on purpose, and latency is not the topic.
And if you are in the middle, where nearly everyone is, the uncomfortable truth is that neither is probably your limit. Before replacing the machine, measure DPC, check the power plan and look at what is hanging on your master. It costs a lot less.
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
