Canvas Audio Frequency Bars — Free Web Audio API Visualizer

This snippet is a real audio-reactive visualizer, not a faked one: click "Use microphone" and it asks for getUserMedia, routes the live stream through a Web Audio AnalyserNode, and paints genuine frequency-bin data to canvas every frame. What makes it worth studying isn't just the Web Audio wiring — it's the fallback path that keeps the demo looking intentional no matter what the browser or embedding context allows.

The real path: getUserMedia to AnalyserNode

navigator.mediaDevices.getUserMedia({ audio: true }) requests the microphone and resolves with a MediaStream. That stream is wrapped in audioCtx.createMediaStreamSource(micStream) and piped into an AnalyserNode with fftSize: 256, which exposes 128 frequency bins. Every animation frame, analyser.getByteFrequencyData(freqData) fills a Uint8Array with the current 0-255 magnitude of each bin — that array, sliced down to BAR_COUNT, is what actually drives every bar's height. smoothingTimeConstant: 0.82 is the analyser's own built-in smoothing, so bars ease between frames instead of jittering on every sample.

Why a fallback is not optional here

Microphone access is one of the few browser APIs that can fail in ways entirely outside your code's control: the user can deny the permission prompt, the browser can lack support, or — very commonly for a snippet rendered inside a sandboxed preview <iframe> — the surrounding page's Permissions-Policy can simply never grant microphone to that frame, so getUserMedia rejects immediately with no prompt shown at all. A visualizer that goes blank in that case looks broken, not permission-restricted.

A simulation indistinguishable from motion

simulatedFrame() blends two sine waves per bar — a slow base term and a faster wobble term — multiplied by a slow-moving envelope that swells and recedes like a breathing loudness curve, then packs the result into the exact same Uint8Array shape getByteFrequencyData would produce. Because drawBars() only ever consumes that shape, the rendering code has no idea whether its data came from a real microphone or from math — which is exactly the point: the fallback isn't a "no audio" message, it's a full visual substitute.

Fail-into-simulation, always

startMic() wraps the entire request in a try/catch; any rejection — NotAllowedError from a denied prompt, NotFoundError with no microphone present, or a security error from a Permissions-Policy block — routes to startSimulated() with a message naming the error. The loop itself never branches on whether the *attempt* succeeded, only on the current mode, so there's exactly one code path that decides what's on screen at any moment. Pair this with an audio waveform visualizer for a player UI, or a particle network background reacting to the same analyser data.