The legacy ScriptProcessorNode ran audio synthesis callbacks directly on the browser main thread. Whenever JavaScript executed heavy layout calculations, DOM mutations, or garbage collection sweeps, the audio thread starved, causing audible clicks, pops, and glitching dropouts. Furthermore, ScriptProcessorNode suffered from a minimum buffer latency of 256 to 16,384 samples (~6ms to 370ms). AudioWorklet executes inside a dedicated, high-priority real-time audio rendering thread with an ultra-low fixed quantum of 128 samples (~2.67ms at 48kHz).

In the W3C Web Audio specification, the audio rendering engine operates in strict chunks of 128 PCM audio samples per channel block (the "render quantum"). At 48,000 Hz sample rate, 128 samples correspond to exactly 2.666 milliseconds of audio. The process() method must compute and write all 128 samples before this 2.67ms deadline expires; failing to do so causes an immediate audio buffer underrun (dropout).

Naive digital waveforms like Sawtooth or Square have instantaneous mathematical discontinuities (vertical edges). In digital signal processing, an instantaneous step contains infinite high frequencies that exceed the Nyquist limit (sample_rate / 2). These unrepresentable frequencies reflect backwards into the audible spectrum as harsh, dissonant aliasing noise. PolyBLEP approximates a band-limited step function using a second-order polynomial, smoothing only the 2 samples surrounding each transition to eliminate aliasing while preserving razor-sharp analog timbre.

AudioWorkletProcessor runs inside a real-time thread where timing must be deterministic to the microsecond. Allocating memory (via new Float32Array(), object literals, or closures) forces the browser JavaScript V8 engine to allocate heap memory, which eventually triggers a Garbage Collection (GC) sweep. When the garbage collector runs, it pauses the audio execution thread, resulting in catastrophic audio dropouts and clicking.