Game Audio Without Libraries: Building a Sound Engine from Scratch

Every sound in every Gerk Games game comes from Web Audio API. No library, no framework, no audio files. Just raw oscillator nodes and gain envelopes.

Why Web Audio API Beats Audio Files

Audio files need to load, decode, and buffer. On a slow connection, that's 2-5 seconds PER SOUND. Web Audio API generates sounds procedurally — zero network overhead, zero file size, zero loading time. A game with 10 sound effects using procedural audio loads instantly.

Our engine is one function: an oscillator with frequency, duration, waveform, and a fade-to-zero gain envelope. That's literally it. Everything from the Snake Arena eating sound to the Pixel Jumper jump sound is just different parameters to the same function.

Web Audio API Architecture

Building a game audio engine from scratch using the Web Audio API requires understanding three core components: the AudioContext, audio nodes, and the connection graph. An AudioContext manages the audio hardware and creates a timeline. Audio nodes (oscillators, gain nodes, buffer sources) connect in a directed graph to produce sound. The connection graph determines routing — an oscillator connects to a gain node which connects to the destination. This node-based architecture is more flexible than loading pre-recorded audio files because sounds can be generated in real-time.

Procedural Sound Design for Games

For game sound effects like coin pickups, jump noises, and collision impacts, procedural generation offers two major advantages: zero download size and infinite variation. A coin pickup can be synthesized with a brief sine wave pitch sweep from 200Hz to 800Hz over 100ms with an exponential decay envelope. A collision sound can be generated by passing white noise through a band-pass filter with rapidly decaying gain. These effects sound natural because they mimic physical acoustic phenomena.

Performance Considerations

Audio processing shares the main thread with game rendering unless explicitly offloaded to AudioWorklet. For performance-critical games, we recommend creating all audio nodes during game initialization rather than during gameplay. Node creation involves memory allocation, which can cause frame drops. Pre-create your oscillator and gain nodes, connect them to the destination, and simply call start() and stop() on the oscillator during gameplay. This approach reduces per-frame audio overhead from approximately 0.5ms to effectively zero.

Building a Complete Sound Set

A complete game requires at least six distinct sound categories: positive feedback (correct selections, pickups), negative feedback (collisions, errors), transition sounds (level start, level complete), ambient loops (background hum), UI sounds (button clicks), and reward sounds (achievement unlocked). Each category can be generated with a different algorithmic approach. Positive feedback uses ascending pitch sweeps. Negative feedback uses noise bursts with rapid decay. Ambient loops use oscillating filters on constant tones. Rewards use layered harmonic sequences.

Testing Audio Timing Under Load

One subtle bug we encountered during development: audio playback timing drifts when the game's frame rate drops. If the game runs at 30fps instead of 60fps, audio events scheduled with setTimeout fire at unpredictable offsets from their visual counterparts. The fix was to schedule all audio events using the AudioContext's internal clock rather than JavaScript timers. The AudioContext.currentTime property provides a hardware-synchronized timestamp that remains accurate regardless of frame rate. This guarantees that sound effects stay synchronized with visual events even on low-end devices where frame rates fluctuate.

Browser Compatibility Testing

Our audio engine has been tested on Chrome 90+, Firefox 90+, Safari 15+, and Edge 90+. Safari was the most challenging target because its Web Audio API implementation has historically lagged behind Chrome and Firefox. Safari does not support AudioWorklet, which means all audio processing must run on the main thread — a significant constraint for games running at 60fps. Our workaround for Safari: reduce audio complexity during gameplay (simpler oscillator shapes, fewer simultaneous voices) and restore full audio quality during menu screens where frame rate is less critical.

Audio files typically use MP3 at roughly 1MB per minute of audio. A game with 10 sound effects at 2 seconds each would need roughly 350KB of audio files. On a 3G connection, that adds 2-3 seconds of loading time. Worse, the browser must decode each audio file before playing it, adding another 200-500ms of latency. Procedural audio using Web Audio API eliminates all of this. Our entire sound engine is about 600 bytes of JavaScript. It loads instantly and plays sounds with zero decoding latency.

The specific technique: an OscillatorNode generates a waveform (sine for musical tones, square for impact sounds, sawtooth for "danger" sounds). A GainNode controls the volume envelope (attack, sustain, decay). By varying these parameters, we can produce a surprising range of sounds. A sine wave at 440Hz with 50ms attack and 200ms decay sounds like a soft button press. A square wave at 200Hz with 5ms attack and 100ms decay sounds like a game over thud. A sawtooth wave at 800Hz with rapid frequency modulation sounds like a power-up activation. All of these come from the same 600-byte function, just called with different parameters.

The Web Audio Oscillator as an Instrument

Building sound from scratch means treating the Web Audio API's oscillator as a primitive instrument. A square wave gives you the classic retro blip; a sine wave gives you a soft tone; a sawtooth gives you a harsh buzz. By scheduling short oscillator bursts at specific frequencies and shaping their volume envelope, you can synthesize every sound effect a casual game needs without loading a single audio file. The advantage is enormous: zero network requests for audio, instant playback, and a total footprint of a few hundred bytes of code instead of megabytes of sample files.

Envelopes Are Everything

The difference between a pleasant sound and an ear-splitting one is the envelope — how the volume ramps up and fades out. A raw oscillator switched on and off produces an unpleasant click at both ends because of the abrupt amplitude change. The fix is a quick fade-in over a few milliseconds and a smooth fade-out, which removes the click and gives the sound a natural shape. Most of the work in scratch-built game audio is not choosing frequencies, it is sculpting these tiny envelopes so the sounds feel intentional rather than harsh.

Why We Avoid Audio Files Entirely

The honest reason we synthesize everything is performance discipline. The moment you add audio files, you add loading time, decoding overhead, and a dependency on the network. For games that promise to load in under two seconds on any connection, audio files are a liability. Synthesized sound keeps the entire game self-contained and instant. The constraint forces creativity, and the result is games that play their first sound effect the instant the page is interactive, with nothing to download.

One surprising discovery from building our sound engine: procedural audio makes game feel more responsive than pre-recorded samples ever could. Because there's zero decode time, sounds fire on the exact frame they're triggered. In Snake Arena, the eating sound plays on the same frame the food disappears. In Flap Bat, the flap sound is perfectly synced with the sprite animation. This frame-perfect sync creates a tactile feel that recorded audio can't match due to buffering latency.

Another practical tip if you're building your own: start with just two sounds — a success sound and a failure sound. Get those feeling right before expanding your palette. We spent three days tuning just the power-up activation sound because it had to be instantly recognizable without being annoying on the 50th play. A good rule: if you don't mind hearing a sound 200 times in a row, it's ready.