Vibe Coding · Creative Tech · Audio Visualization
AudVis
A real-time audio visualizer built on HTML5 Canvas and the Web Audio API — supporting mic input, file upload, and streaming from YouTube, Spotify, and Apple Music. Four visualization modes, volume control, and sensitivity tuning. Vanilla JavaScript, zero dependencies.
Overview
Sound you can see, built entirely in the browser.
AudVis started as a challenge to myself: could I build something visually impressive using only browser-native APIs with zero external libraries? The answer was yes — and the process taught me more about real-time graphics rendering and audio processing than any tutorial could.
The result is an interactive audio visualizer that accepts sound from three different sources, transforms raw frequency data via FFT analysis, and renders it in real time across four distinct visualization modes. It has since grown into a proper multi-file project — separated HTML, CSS, JS, and a dedicated streaming service module — running at smooth 60fps framerates with volume control and adjustable sensitivity.
The Challenge
Real-time graphics and audio processing are unforgiving.
Canvas animations have no safety net. A poorly optimized render loop drops frames immediately and visibly. Combining that with live audio analysis — where the data updates 60 times per second — meant every decision had a direct performance cost.
Audio pipeline complexity
Each input source — microphone, file, stream — needs its own routing through the Web Audio API graph. Building a unified interface over three different source types without redundant code was the first real design challenge.
Canvas performance
Clearing and redrawing the entire canvas every frame is
expensive. I had to learn which operations to batch, when to use
requestAnimationFrame
vs setInterval, and how to avoid unnecessary state changes.
Technical Architecture
Web Audio API does the heavy lifting.
The Web Audio API exposes an
AnalyserNode
that performs Fast Fourier Transform (FFT) analysis on live audio,
returning frequency-domain data as a byte array. That array is what
drives every visual — each bar, wave, and particle maps directly to
a frequency bucket. The analyser runs at an FFT size of 256 with a
smoothing time constant of 0.8, striking a balance between frequency
resolution and smooth transitions.
streaming-service.js
handles platform detection and URL validation for YouTube,
Spotify, and Apple Music — cleanly separated from the core
visualizer logic.
Visualization Modes
Four ways to see the same sound.
Each mode uses the same underlying frequency data but visualizes it with a completely different algorithm. Building each one from scratch deepened my understanding of the data itself — how frequency buckets cluster, how amplitude maps to perceived loudness, how time-domain vs frequency-domain data behaves.
What I Learned
Performance is a design decision.
This project changed how I think about front-end work. Every line of code in a render loop has a cost that shows up visibly and immediately. That feedback loop — write something, see it stutter, figure out why — made performance optimization feel less like an optimization and more like a design constraint I had to work within from the start.
I also developed a much deeper appreciation for what browser APIs can actually do. The Web Audio API's node graph architecture is genuinely elegant — routing audio through composable nodes mirrors how physical signal chains work, which made understanding it feel intuitive once it clicked.