Remix.run Logo
I underestimated how hard audio waveforms are in the browser
4 points by syncara 15 hours ago | 2 comments

A few months ago I thought displaying an audio waveform in the browser would be a weekend project.

I was wrong.

The first prototype worked fine with short audio clips, but everything fell apart when I tried loading recordings that were several hours long.

Memory usage exploded.

The UI became unresponsive.

Zooming was painful.

Even generating waveform peaks took longer than expected.

What surprised me most is that the actual challenge wasn't decoding audio. It was rendering and managing huge amounts of timeline data efficiently.

I ended up experimenting with Web Workers, IndexedDB caching, virtualized rendering and progressive loading strategies just to keep the browser responsive.

For those who have built browser-based audio tools:

What was the hardest performance bottleneck you encountered?

Was it decoding, rendering, memory management, or something else entirely?

dostick 2 hours ago | parent | next [-]

Do you mean rendering realtime visualisation, or static map representation of the audio?

Nikolaus018 4 hours ago | parent | prev [-]

The DOM chokes so fast if you try to render thousands of SVGs or divs for this.

If you haven't already, just dump the data into an HTML5 <canvas> using requestAnimationFrame. Pulling the byte frequency data from the Web Audio API and drawing it straight to a canvas buffer is pretty much the only way to keep it at a smooth 60fps without killing the browser.