Browser audio processing and practical troubleshooting
Understand Web Audio, AudioWorklet, WASM, and WebGPU, then distinguish model loading, memory limits, and playback glitches.
A browser DAW combines interface work, audio playback, and model computation. “Runs in the browser” does not mean every feature uses the same execution path.
Different roles
| Technology | Role | Common misconception |
|---|---|---|
| Web Audio | Playback, routing, levels, effects | It does not by itself perform AI separation |
| AudioWorklet | Audio-processing execution | It does not offer unlimited computation per block |
| WebAssembly | Execute compiled computation | It is not automatically GPU processing |
| WebGPU | GPU computation | A browser name alone does not guarantee availability |
Separate downloading from computation
First use may download models and WASM assets. Determine whether a stalled operation is still downloading or already computing. A faster second run can reflect caching rather than faster GPU computation.
Why long files need more memory
Editing can decode a 16-bit PCM file into 32-bit floating-point samples. One float32 copy of ten minutes of 48 kHz stereo takes 48,000 × 2 × 600 × 4 = 230,400,000 bytes. Models, intermediate buffers, and separate stems add more. Compressed file size is not the memory requirement.
Playback glitches versus analysis failures
For playback glitches, close heavy tabs, reduce active effects, and test a short source. For analysis failures, check format, duration, and GPU availability separately. Local Standard processing and cloud HQ processing can fail for different reasons.
Report a reproducible issue
Record device, OS, browser version, tool and mode, source format and duration, and the step that failed. You do not need to send unreleased audio. Use Contact to describe the reproduction steps.