Como Funcionam os Geradores Digitais de Ruído

A Base: Geração de Números Pseudoaleatórios

No meu trabalho construindo o motor de ruído no WhiteNoise.top, passei centenas de horas otimizando o pipeline que transforma aleatoriedade matemática em áudio convincente. Todo gerador digital de ruído começa com o mesmo componente fundamental: um gerador de números pseudoaleatórios, ou PRNG. Um PRNG é um algoritmo que produz uma sequência determinística de números que parece aleatória de acordo com testes estatísticos. Aleatoriedade verdadeira de fontes de entropia de hardware é muito lenta e imprevisível para áudio em tempo real, então PRNGs fornecem a base prática para toda geração digital de ruído.

O PRNG mais básico adequado para trabalho de áudio é o gerador congruencial linear (LCG), que computa cada valor como uma função linear do valor anterior, módulo uma grande constante. Embora rápido, LCGs têm fraquezas conhecidas: eles exibem correlações entre amostras sucessivas que podem produzir artefatos audíveis em sinais de ruído. Nos meus primeiros protótipos, usei um LCG simples e podia ouvir padrões periódicos fracos na saída ao ouvir com fones de ouvido de alta qualidade. Esses padrões apareciam como picos espectrais estreitos na análise FFT, confirmando que as fraquezas estatísticas do PRNG estavam vazando para o domínio do áudio.

Para ruído de qualidade de produção, mudei para o algoritmo xorshift128+, que é o PRNG usado internamente pela maioria dos motores JavaScript para Math.random(). Ele tem um período de 2 elevado à potência 128 menos 1, excelentes propriedades estatísticas e custo computacional negligenciável. Quando executo a bateria de testes de aleatoriedade TestU01 em sua saída, ele passa em todas as suítes SmallCrush e Crush. O resultado é um sinal de ruído livre de artefatos audíveis, com um espectro plano verificado dentro de 0,3 dB em toda a faixa audível.

De Números Aleatórios a Amostras de Áudio

Um PRNG produz números, mas um sistema de áudio precisa de amostras de forma de onda em amplitudes e taxas de amostragem específicas. O processo de conversão envolve escalonamento, moldagem de distribuição e gerenciamento de buffer. Na minha implementação, o PRNG produz inteiros sem sinal de 32 bits, que então normalizo para valores de ponto flutuante na faixa de menos um a mais um. Esta é a faixa de amplitude padrão para áudio digital na Web Audio API e na maioria dos outros frameworks de áudio.

A distribuição dos valores aleatórios importa para o caráter do ruído. Uma distribuição uniforme, onde todos os valores na faixa são igualmente prováveis, produz ruído com uma distribuição de amplitude ligeiramente diferente da distribuição Gaussiana que caracteriza o ruído térmico em circuitos analógicos. Na prática, a diferença é sutil: o ruído branco uniforme tem um fator de crista de cerca de 4,8 dB, enquanto o ruído branco Gaussiano tem um fator de crista teoricamente ilimitado, embora na prática esteja em torno de 12 dB para comprimentos de buffer típicos. Para a maioria das aplicações, a distribuição uniforme é perfeitamente aceitável e computacionalmente mais simples.

Quando preciso de ruído com distribuição Gaussiana para aplicações que o exigem, uso a transformada Box-Muller, que converte pares de números aleatórios uniformemente distribuídos em pares de valores com distribuição Gaussiana. O overhead computacional é modesto — aproximadamente dobrando o custo por amostra — mas o resultado é um sinal de ruído que corresponde mais de perto às estatísticas de amplitude de fontes de ruído analógicas. Em testes de escuta, a diferença entre ruído branco uniforme e Gaussiano é quase inaudível, mas a variante Gaussiana tem melhor desempenho em certas aplicações de processamento de sinais onde as estatísticas de amplitude importam.

Moldagem Espectral: Transformando Branco em Cores

O ruído branco é a matéria-prima a partir da qual todas as outras cores de ruído são criadas. A transformação é realizada por filtragem digital — aplicando uma curva de ganho dependente de frequência ao espectro do ruído branco. No meu motor de ruído, implemento moldagem espectral usando filtros IIR (resposta ao impulso infinita) e FIR (resposta ao impulso finita), cada um com vantagens distintas.

Para ruído rosa (inclinação de menos três decibéis por oitava), uso o algoritmo Voss-McCartney como meu método principal. Este algoritmo mantém múltiplos geradores de números aleatórios independentes que atualizam em taxas diferentes: um atualiza a cada amostra, um a cada duas amostras, um a cada quatro amostras, e assim por diante. As saídas são somadas para produzir um sinal cujo espectro aproxima a inclinação ideal de ruído rosa. Na minha implementação, uso 16 camadas de oitava, o que fornece moldagem espectral precisa de abaixo de 1 Hz até acima de 20 kHz. O erro em relação à inclinação ideal é menor que 0,5 dB em toda a faixa audível.

Para ruído marrom (inclinação de menos seis decibéis por oitava), uso integração simples: cada amostra de saída é a soma da saída anterior e uma nova amostra de ruído branco, escalonada por um pequeno coeficiente. Matematicamente, este é um filtro passa-baixa IIR de primeira ordem com um polo muito próximo de um no círculo unitário. O desafio com essa abordagem é a deriva DC: a soma acumulada pode vaguear para longe de zero ao longo do tempo, eventualmente excedendo o limiar de corte. Resolvo isso adicionando um filtro passa-alta de primeira ordem muito suave a 5 Hz, que restringe a deriva sem afetar audivelmente o espectro acima de 20 Hz.

Para formas espectrais personalizadas solicitadas por usuários avançados, uso um equalizador paramétrico construído a partir de seções de filtro biquad de segunda ordem em cascata. Cada seção implementa um tipo de filtro padrão (pico, estante grave, estante aguda ou notch) com frequência, ganho e largura de banda ajustáveis pelo usuário. Ao encadear quatro a seis seções, posso aproximar virtualmente qualquer forma espectral suave que um usuário possa querer, desde inclinações suaves até contornos complexos de múltiplas bandas.

Geração em Tempo Real com a Web Audio API

A Web Audio API, disponível em todos os navegadores modernos, fornece a infraestrutura para gerar e reproduzir ruído em tempo real sem qualquer processamento do lado do servidor. Na minha implementação no WhiteNoise.top, uso três componentes principais da Web Audio API: o AudioContext, o ScriptProcessorNode (ou seu substituto moderno, o AudioWorkletNode) e o BiquadFilterNode.

O AudioWorkletNode é onde a geração principal acontece. Registro um AudioWorkletProcessor personalizado que roda em um thread separado do thread principal do navegador, garantindo que interações de UI não causem falhas no áudio. O método process() do processador é chamado repetidamente com um buffer de saída, tipicamente 128 amostras por chamada a 44,1 kHz. Dentro deste método, gero amostras de ruído branco usando o PRNG, aplico qualquer moldagem espectral e escrevo os resultados no buffer de saída. Todo o pipeline roda em cerca de 0,01 milissegundos por buffer em hardware moderno, bem dentro do prazo de aproximadamente três milissegundos para reprodução sem falhas.

O gerenciamento de buffer é crítico para evitar artefatos audíveis. Se o processador demora muito para preencher um buffer, a saída de áudio sofre underrun, produzindo um clique ou estalo. Nos meus testes de estresse, pressiono o sistema adicionando carga computacional ao thread principal (como manipulação pesada de DOM ou análise de JSON grande) e verifico que o thread do audio worklet continua a entregar buffers no prazo. O isolamento de thread fornecido pela API AudioWorklet é essencial para essa robustez; o ScriptProcessorNode mais antigo rodava no thread principal e era vulnerável a falhas durante execução pesada de JavaScript.

Também uso o BiquadFilterNode embutido da Web Audio API para moldagem espectral quando o filtro desejado é um tipo padrão. Esses nós são implementados em código nativo otimizado, tornando-os significativamente mais rápidos que implementações JavaScript equivalentes. Para geração de ruído rosa em configurações mais simples, coloco em cascata vários BiquadFilterNodes configurados como filtros passa-baixa com frequências e fatores Q cuidadosamente escolhidos para aproximar a inclinação ideal de menos três decibéis por oitava.

Otimizações e Considerações Práticas

A otimização de desempenho é uma preocupação contínua na geração de áudio em tempo real. No meu processo de desenvolvimento, implementei várias técnicas para maximizar a eficiência sem sacrificar a qualidade. A primeira é pré-computação: para cores de ruído que não mudam dinamicamente, gero um grande buffer de ruído (tipicamente 10 segundos a 44,1 kHz, ou 441.000 amostras) durante a inicialização e o repito durante a reprodução. Para evitar que o loop seja audível, uso um crossfade no limite do loop, misturando as últimas 4.096 amostras do buffer com as primeiras 4.096 amostras usando uma janela de cosseno elevado. O loop resultante é perceptualmente contínuo.

A segunda otimização é o processamento estilo SIMD dentro do JavaScript. Embora o JavaScript não forneça instruções SIMD explícitas no contexto do AudioWorklet, estruturo meus loops internos para processar amostras em grupos de quatro, permitindo que o compilador JIT do motor JavaScript aplique auto-vetorização. Nos meus benchmarks, essa abordagem produz uma aceleração de 15 a 25 por cento comparada ao processamento de uma amostra por vez, dependendo do motor do navegador.

Uma terceira consideração é o gerenciamento de memória. Alocar e desalocar memória durante o processamento de áudio pode disparar pausas de coleta de lixo, que causam falhas audíveis. Pré-aloco todos os buffers durante a inicialização e os reutilizo durante toda a sessão. Nenhum objeto é criado dentro do método process(), e todos os valores intermediários são armazenados em arrays tipados pré-alocados. Essa disciplina elimina completamente os artefatos de áudio relacionados ao GC.

O consumo de energia é outra preocupação prática, especialmente para dispositivos móveis. Nos meus testes em smartphones, descobri que a carga de CPU de um gerador de ruído simples é negligenciável — tipicamente menos de um por cento. No entanto, manter a saída de áudio ativa impede o dispositivo de entrar em estados de sono profundo, o que pode drenar a bateria em sessões prolongadas. Mitigo isso oferecendo um recurso de temporizador que para o gerador após uma duração especificada pelo usuário, e usando a API de Visibilidade de Página para pausar a geração quando a aba do navegador não está em primeiro plano.

Validando a Qualidade da Saída do Gerador

Um gerador de ruído é tão bom quanto a qualidade de sua saída, e a qualidade deve ser verificada por meio de medição objetiva. No meu processo de garantia de qualidade, executo cada configuração de gerador por uma suíte de testes automatizados antes de liberá-la para os usuários. O primeiro teste é planura espectral: capturo uma amostra de 60 segundos de ruído branco, computo a magnitude FFT média e verifico que nenhum bin de frequência se desvia mais de 1 dB da média. Para ruído moldado, comparo o espectro medido com a curva alvo e verifico se o desvio é menor que 0,5 dB.

O segundo teste é a distribuição de amplitude. Computo um histograma dos valores das amostras e o comparo com a distribuição esperada — seja uniforme ou Gaussiana — usando o teste de Kolmogorov-Smirnov. Um valor p acima de 0,05 indica que a distribuição corresponde à forma esperada no nível de confiança de 95 por cento.

O terceiro teste é a detecção de periodicidade. Computo a função de autocorrelação de uma amostra de 10 segundos e verifico que nenhum atraso diferente de zero tem um coeficiente de correlação excedendo o máximo teórico para um processo aleatório daquele comprimento. Padrões periódicos no PRNG apareceriam como picos na função de autocorrelação, mesmo que não sejam audíveis, e indicam uma falha no gerador que poderia causar problemas em aplicações de processamento de sinais.

Finalmente, realizo testes de escuta subjetivos com fones de ouvido, verificando cliques, estalos, artefatos tonais e variações em nível ou timbre durante períodos de reprodução prolongados. Testes automatizados detectam a maioria dos problemas, mas o ouvido humano permanece o juiz final da qualidade de áudio, e faço questão de ouvir pessoalmente cada variante do gerador antes de ir ao ar na plataforma.