WebAssembly: remove usage of deprecated api

[vkuznetsovgn]

When initializing ma_engine on WebAssembly, there is a deprecation warning in a Chrome development console:

[Deprecation] The ScriptProcessorNode is deprecated. Use AudioWorkletNode instead. (https://bit.ly/audio-worklet)

I believe it's better to avoid using deprecated functionality.

Environment:
emsdk: 3.1.14
Chrome: 108.0.5359.79

[mackron]

There's no way to support this without using a separate .js file which is something I won't be doing. Until there's a way to use AudioWorkletNode without a separate file there's nothing I can do.

[eddyc]

Emscripten has apparently added support for AudioWorklets, so it may be possible to add this now:
https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3132---021723

[mackron]

Thanks for the heads up. I'll reopen this one to remind me to take a look. But no promises I'll add support for this - if it doesn't work well with miniaudio's single-file architecture or complicates the build system I won't be adding it.

[mackron]

I've had a look at this and it actually seems pretty good. I've pushed an initial implementation to the dev branch. It's currently opt-in because it's still not fully tested and requires changes to the build command. To use this, you need to specify the following with the emcc command: -sAUDIO_WORKLET=1 -sWASM_WORKERS=1 -sASYNCIFY.

The AUDIO_WORKLET and WASM_WORKERS items are for enabling AudioWorklets. The ASYNCIFY item is for doing some synchronization stuff since the Emscripten API seems to be mostly async.

In addition to the above, you need to tell miniaudio itself to use the AudioWorklets path which you can do with MA_ENABLE_AUDIO_WORKLETS.

#define MA_ENABLE_AUDIO_WORKLETS
#define MINIAUDIO_IMPLEMENTATION
#include "miniaudio.h"

Alternatively, just add it to the command line: -DMA_ENABLE_AUDIO_WORKLETS.

I've only done very limited testing so far. Playback seems to work nicely, but my simple_duplex example sounds terrible on Firefox and Chrome. Interestingly it sounds really good on Opera, however. I'm not sure what's going on there. My suspicion is that the internal buffer is too small. As per the WebAudio specification, the size of the buffer supplied to the processing callback is only 128 frames, which at a sample rate of 48000 is only 2.6ms. I'm suspecting this is too small and the browser is struggling to keep up. Can't know for sure though.

I also noticed that my simple_duplex example breaks when specifying 44100 as the sample rate instead of 48000. Haven't figured that one out yet. Pretty sure it's on the capture side.

If you were to play around with this I'd be very interested in hearing some early feedback.

[eddyc]

Thanks for implementing this, I'll check it out this week and let you know if there's any issues that arise from testing

[mackron]

I've done some more work on this. The issue I mentioned earlier about duplex sounding terrible is something I can't seem to work around. It's happening in both Firefox and Chromium based browsers. Not sure what's going on there, but even when I build a simple HTML/JS test where the AudioWorklet node simply passes the input straight through to the output I still get the same behaviour so I'm quite convinced this is a browser issue. That will have to just stay as-is.

The sample rate issue I mentioned earlier has also been addressed. On the capture side, the native sample rate is always used, and resampling is just done manually by miniaudio. Ideally this would be done by the browser itself, but I couldn't get it working reliably across all browsers (we can blame Firefox for this one) so we'll just have to deal with it.

I'm going to call this one done and close this ticket. This work is in the dev branch and will be in the next release.