emscripten compiler/linker settings?

[thomthom]

I'm using miniaudio in an ftxui TUI app. Works great on desktop, now I'm trying to build using emscripten.

The audio fails to initialize and I tracked it down to somewhere in ma_context_init__webaudio. Here I'm getting an error code from the JS script executed (resultFromJS = EM_ASM_INT)

While I cannot step into the JS code from WASM I notice that the callstack is from a pthread, not main. And when I tried window in the developer console with the context of that thread there was no window object.

I tried to build without pthread (USE_PTHREAD), but then ftxui failed, it appear to need threads to run its loop. I also tried to not build with PROXY_TO_PTHREAD but that lead to errors when ftxui start, about blocking main thread.

I tried with ASYNCIFY and ALLOW_BLOCKING_ON_MAIN_THREAD as well to see if that would allow the miniaudio webaudio init logic to run on main thread, but then I get another error from emscripten about blocking the main thread, which appear to be from ftxui's loop;

I'm starting to wonder if miniaudio might not be compatible in emscripten builds that also builds ftxui.

I was wondering if my rambling above makes sense? This is an issue with miniaudio needing to be run in the main thread, not compatible with PROXY_TO_PTHREAD?

[mackron]

I'm not actually sure what's going on here. I didn't think there was any blocking going on in the context initialization stuff so I'm kind of surprised there'd be an error in ma_context_init__webaudio(). Have you by chance tried running miniaudio's Emscripten test: https://github.com/mackron/miniaudio/tree/master/tests/emscripten?

[thomthom]

It's not miniaudio doing blocking calls, it's ftxui, which is probably why it needs PROXY_TO_PTHREAD which shifts it off the main thread. But, that means, when I try to initialize miniaudio in a ftxui button, that's not happening in the main thread and the window object is not available causing the JS code in ma_context_init__webaudio to fail.

The miniaudio's Emscripten test, what compiler flag is it using? From the CMakeLists.txt it looks to be using mostly default flags?

[thomthom]

Oh, I just learned about MAIN_THREAD_EM_ASM_INT. Since window.AudioContext exists only in the main thread I think ma_context_init__webaudio should be using MAIN_THREAD_EM_ASM_INT instead of EM_ASM_INT.

[mackron]

Yes, just default flags. If you want to enable the Audio Worklets path, you need to add -sAUDIO_WORKLET=1 -sWASM_WORKERS=1 -DMA_ENABLE_AUDIO_WORKLETS

I had never heard of MAIN_THREAD_EM_ASM before. Does using that indeed fix the ma_context_init__webaudio() call for you? Would that also need to be used everywhere else? I'll need to consider it.

[thomthom]

I haven't tried audio worklets yet. That's all new to me, along with emscripten and Web Audio, so I'm reading my way through it.

But looking briefly at audio worklet examples I see that they are created from AudioContext objects, which needs to be created in the browser's main thread. I haven't tried to configure my test project to use audio worklets yet, but I suspect it will also fail.

I've been reading the miniaudio source and I don't have a good enough understanding to whether all EM_ASM calls should be using MAIN_THREAD_ variants in case PROXY_TO_PTHREAD is used. I'll do some experiments.

[mackron]

It's no worries, I didn't mean for you to do any leg work or anything. I was mostly just interested if you had experimented with it. Web is not my area of expertise either so I'm not sure myself on much of this stuff.

[thomthom]

I did a "blind" replace of all EM_ASM call to use the MAIN_THREAD_ variants: https://github.com/thomthom/miniaudio/tree/dev/em-asm-from-main-thread

But I surprisingly got errors about mismatched arguments then:

It's not immediately obvious to me why I'd get that kind of error. The calling signature of EM_ASM vs THREAD_MAIN_EM_ASM is the same...

I've been suffering the flu the last few days, so progress has halted for now.

I did however make my minimal test project public if it should be of interest to anyone: https://github.com/thomthom/wasm-ftxui-test/tree/dev/miniaudio-patch

As an aside, miniaudio works great on desktop and I got some neat retro like sounds for my TUI minesweeper clone 😃

While I'm trying to figure out ftxui+miniaudio+emscripten I am currently emitting a callback to JS in emscripten builds and reimplemented the audio generator in JS.