How Digital Noise Generators Work

The Foundation: Pseudorandom Number Generation

In my work building the noise engine at WhiteNoise.top, I have spent hundreds of hours optimizing the pipeline that turns mathematical randomness into convincing audio. Every digital noise generator starts with the same fundamental component: a pseudorandom number generator, or PRNG. A PRNG is an algorithm that produces a deterministic sequence of numbers that appears random according to statistical tests. True randomness from hardware entropy sources is too slow and unpredictable for real-time audio, so PRNGs provide the practical foundation for all digital noise generation.

The most basic PRNG suitable for audio work is the linear congruential generator (LCG), which computes each value as a linear function of the previous value, modulo a large constant. While fast, LCGs have known weaknesses: they exhibit correlations between successive samples that can produce audible artifacts in noise signals. In my early prototypes, I used a simple LCG and could hear faint periodic patterns in the output when listening through high-quality headphones. These patterns appeared as narrow spectral peaks in the FFT analysis, confirming that the PRNG's statistical weaknesses were leaking into the audio domain.

For production-quality noise, I switched to the xorshift128+ algorithm, which is the PRNG used internally by most JavaScript engines for Math.random(). It has a period of 2 to the power of 128 minus 1, excellent statistical properties, and negligible computational cost. When I run the TestU01 battery of randomness tests on its output, it passes all of the SmallCrush and Crush suites. The result is a noise signal free of audible artifacts, with a flat spectrum verified to within 0.3 dB across the audible range.

From Random Numbers to Audio Samples

A PRNG produces numbers, but an audio system needs waveform samples at specific amplitudes and sample rates. The conversion process involves scaling, distribution shaping, and buffer management. In my implementation, the PRNG outputs unsigned 32-bit integers, which I then normalize to floating-point values in the range of negative one to positive one. This is the standard amplitude range for digital audio in the Web Audio API and most other audio frameworks.

The distribution of the random values matters for the character of the noise. A uniform distribution, where all values in the range are equally likely, produces noise with a slightly different amplitude distribution than the Gaussian distribution that characterizes thermal noise in analog circuits. In practice, the difference is subtle: uniform white noise has a crest factor of about 4.8 dB, while Gaussian white noise has a theoretically unbounded crest factor, though in practice it is around 12 dB for typical buffer lengths. For most applications, uniform distribution is perfectly acceptable and computationally simpler.

When I need Gaussian-distributed noise for applications that demand it, I use the Box-Muller transform, which converts pairs of uniformly distributed random numbers into pairs of Gaussian-distributed values. The computational overhead is modest, roughly doubling the per-sample cost, but the result is a noise signal that more closely matches the amplitude statistics of analog noise sources. In listening tests, the difference between uniform and Gaussian white noise is nearly inaudible, but the Gaussian variant performs better in certain signal processing applications where amplitude statistics matter.

Spectral Shaping: Turning White into Colors

White noise is the raw material from which all other noise colors are created. The transformation is accomplished through digital filtering, applying a frequency-dependent gain curve to the white noise spectrum. In my noise engine, I implement spectral shaping using both IIR (infinite impulse response) and FIR (finite impulse response) filters, each with distinct advantages.

For pink noise (minus three decibels per octave slope), I use the Voss-McCartney algorithm as my primary method. This algorithm maintains multiple independent random number generators that update at different rates: one updates every sample, one every two samples, one every four samples, and so on. The outputs are summed to produce a signal whose spectrum approximates the ideal pink noise slope. In my implementation, I use 16 octave layers, which provides accurate spectral shaping from below 1 Hz to above 20 kHz. The error relative to the ideal slope is less than 0.5 dB across the audible range.

For brown noise (minus six decibels per octave slope), I use simple integration: each output sample is the sum of the previous output and a new white-noise sample, scaled by a small coefficient. Mathematically, this is a first-order IIR low-pass filter with a pole very close to one on the unit circle. The challenge with this approach is DC drift: the running sum can wander far from zero over time, eventually exceeding the clipping threshold. I solve this by adding a very gentle first-order high-pass filter at 5 Hz, which constrains the drift without audibly affecting the spectrum above 20 Hz.

For custom spectral shapes requested by advanced users, I use a parametric equalizer built from cascaded second-order biquad filter sections. Each section implements a standard filter type (peak, low shelf, high shelf, or notch) with user-adjustable frequency, gain, and bandwidth parameters. By chaining four to six sections, I can approximate virtually any smooth spectral shape that a user might want, from gentle tilts to complex multi-band contours.

Real-Time Generation with the Web Audio API

The Web Audio API, available in all modern browsers, provides the infrastructure for generating and playing noise in real time without any server-side processing. In my implementation at WhiteNoise.top, I use three main Web Audio API components: the AudioContext, the ScriptProcessorNode (or its modern replacement, the AudioWorkletNode), and the BiquadFilterNode.

The AudioWorkletNode is where the core generation happens. I register a custom AudioWorkletProcessor that runs on a separate thread from the main browser thread, ensuring that UI interactions do not cause audio glitches. The processor's process() method is called repeatedly with an output buffer, typically 128 samples per call at 44.1 kHz. Inside this method, I generate white noise samples using the PRNG, apply any spectral shaping, and write the results to the output buffer. The entire pipeline runs in about 0.01 milliseconds per buffer on modern hardware, well within the roughly three-millisecond deadline for glitch-free playback.

Buffer management is critical for avoiding audible artifacts. If the processor takes too long to fill a buffer, the audio output underruns, producing a click or pop. In my stress testing, I push the system by adding computational load to the main thread (such as heavy DOM manipulation or large JSON parsing) and verify that the audio worklet thread continues to deliver buffers on time. The thread isolation provided by the AudioWorklet API is essential for this robustness; the older ScriptProcessorNode ran on the main thread and was vulnerable to glitches during heavy JavaScript execution.

I also use the Web Audio API's built-in BiquadFilterNode for spectral shaping when the desired filter is a standard type. These nodes are implemented in optimized native code, making them significantly faster than equivalent JavaScript implementations. For pink noise generation in simpler configurations, I cascade several BiquadFilterNodes configured as low-pass filters with carefully chosen frequencies and Q factors to approximate the ideal minus-three-decibel-per-octave slope.

Optimizations and Practical Considerations

Performance optimization is an ongoing concern in real-time audio generation. In my development process, I have implemented several techniques to maximize efficiency without sacrificing quality. The first is precomputation: for noise colors that do not change dynamically, I generate a large buffer of noise (typically 10 seconds at 44.1 kHz, or 441,000 samples) during initialization and loop it during playback. To prevent the loop from being audible, I use a crossfade at the loop boundary, blending the last 4,096 samples of the buffer with the first 4,096 samples using a raised-cosine window. The resulting loop is perceptually seamless.

The second optimization is SIMD-style processing within JavaScript. Although JavaScript does not provide explicit SIMD instructions in the AudioWorklet context, I structure my inner loops to process samples in groups of four, allowing the JavaScript engine's JIT compiler to apply auto-vectorization. In my benchmarks, this approach yields a 15 to 25 percent speedup compared to processing one sample at a time, depending on the browser engine.

A third consideration is memory management. Allocating and deallocating memory during audio processing can trigger garbage collection pauses, which cause audible glitches. I preallocate all buffers during initialization and reuse them throughout the session. No objects are created inside the process() method, and all intermediate values are stored in pre-allocated typed arrays. This discipline eliminates GC-related audio artifacts entirely.

Power consumption is another practical concern, especially for mobile devices. In my testing on smartphones, I have found that the CPU load from a simple noise generator is negligible, typically less than one percent. However, keeping the audio output active prevents the device from entering deep sleep states, which can drain the battery over extended sessions. I mitigate this by offering a timer feature that stops the generator after a user-specified duration, and by using the Page Visibility API to pause generation when the browser tab is not in the foreground.

Validating Generator Output Quality

A noise generator is only as good as its output quality, and quality must be verified through objective measurement. In my quality assurance process, I run every generator configuration through a suite of automated tests before releasing it to users. The first test is spectral flatness: I capture a 60-second sample of white noise, compute the averaged FFT magnitude, and verify that no frequency bin deviates by more than 1 dB from the mean. For shaped noise, I compare the measured spectrum to the target curve and verify the deviation is less than 0.5 dB.

The second test is amplitude distribution. I compute a histogram of sample values and compare it to the expected distribution, whether uniform or Gaussian, using the Kolmogorov-Smirnov test. A p-value above 0.05 indicates that the distribution matches the expected shape at the 95 percent confidence level.

The third test is periodicity detection. I compute the autocorrelation function of a 10-second sample and check that no non-zero lag has a correlation coefficient exceeding the theoretical maximum for a random process of that length. Periodic patterns in the PRNG would appear as peaks in the autocorrelation function, even if they are not audible, and indicate a flaw in the generator that could cause problems in signal processing applications.

Finally, I perform subjective listening tests with headphones, checking for clicks, pops, tonal artifacts, and variations in level or timbre over extended playback periods. Automated tests catch most problems, but the human ear remains the ultimate judge of audio quality, and I make a point of listening to every generator variant personally before it goes live on the platform.