emscripten-core / emscripten-core/emscripten

Feedback on AudioWorklets API

Open
#18,853 13 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
27.6k
Forks
3.6k
Avg merge
1d 1h
Merged PRs (30d)
105

Description

With the newly added support for AudioWorklets to Emscripten I've been adding support for it to my audio library. I just had a few things that I thought I'd bring up in case it might be of interest to the maintainers.

Is there no function for suspending an AudioContext? There is a `emscripten_resume_audio_context_sync()` but there's no `emscripten_suspend_audio_context_sync()`. Is this an oversight? As it stands now I need to manually write some embedded JavaScript for suspending.

I don't like that the buffer size seems to be hard coded to 128. The MDN documentation says the following (https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Using_AudioWorklet#the_input_and_output_lists):

By specification, each block of audio your process() function receives contains 128 frames (that is, 128 samples
for each channel), but it is planned that this value will change in the future, and may in fact vary depending on
circumstances, so you should always check the array's length rather than assuming a particular size.

Personally, I'd like the see a variable be used to carry this value, with the Emscripten documentation only ever referring to said variable rather than explicitly mentioning the 128 magic number. Is the Emscripten implementation currently robust enough to handle cases when the browser might report a value other than 128 as indicated by the MDN comment above? If the Emscripten implementation is indeed hard coded to 128, even if it's specified as such by the WebAudio spec, I would consider this to be very bad practice, and in my opinion needs to be addressed.

This is a bit more of a nit-picky thing, and I'm not sure how feasible this would be in practice, but it would be really nice to have synchronous versions of async functions. My library implements multiple backends across all the major platforms, and the abstraction requires that everything be synchronous, which I think is reasonable and a fairly common scenario. It gets annoying having to link to `-sASYNCIFY` and doing `emscripten_sleep()` in a loop while it waits for initialization to complete. What I was hoping for was something like this:

```c
EM_BOOL result = emscripten_start_wasm_audio_worklet_thread_sync(audioContext, pStackBuffer, stackSize);
if (result == EM_FALSE) {
// Error.
}
```

And the same with `emscripten_create_wasm_audio_worklet_processor_async()`:

```c
EM_BOOL result = emscripten_create_wasm_audio_worklet_processor_sync(audioContext, &workletProcessorOptions);
if (result == EM_FALSE) {
// Error.
}
```

In my opinion this is just so much cleaner than having to fluff around with callbacks and running a polling loop while the calling thread waits for everything to complete.

That's all I had for the moment. Thanks a lot for your work on this AudioWorklets stuff. Overall it seems to work really well!

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.