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.
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.