> I hear a few problems with the audio emulation, (mostly clicks that shouldn't be there)
Almost anything WASM+Audio seems to do that in browsers today, unless you're really really careful about what you're doing and leverage multiple threads. I think the issue is mostly around single-thread contexts, where it has to switch between playing audio and other things.
I hit the very same issue myself with Bevy not too long time ago, and tracking this issue which has some further links if you wanna go down a rabbit-hole: https://github.com/bevyengine/bevy/issues/4078
What I've found is that essentially WebAudio has such a terrible performance that the audio buffers need to be at minimum 100ms. And if you have a bad frame or any jank in your RAF is likely to glitch at least occasionally.
Compare this to when running natively 20ms audio buffers are fine.
I've settled on a design where I run all the audio graphs and audio decoding in a separate thread and then queue the audio buffers for the main JS thread to pick up and make the WebAudio calls. The same has to be done for the graphics (WebGL) as well. This can be major paradigm shift if the initial design has been done around doing stuff independently on the background. On the web.. no can do.
Bonus tip, if you're planning to use the OpenAL implementation that Emscripten provides my only advice is.. don't.
Almost anything WASM+Audio seems to do that in browsers today, unless you're really really careful about what you're doing and leverage multiple threads. I think the issue is mostly around single-thread contexts, where it has to switch between playing audio and other things.
I hit the very same issue myself with Bevy not too long time ago, and tracking this issue which has some further links if you wanna go down a rabbit-hole: https://github.com/bevyengine/bevy/issues/4078