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?
Nikolaus018•10h ago
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.