I guess we're using two different kinds of mechanisms in delivering the messages with an offline context with a audio worklet.

andre.michelle@

I understand your concern, but I don't think this is an error or flaw. These are two different channels of async comm, and there is no synchronization device between channels.

The MessagePort has its own queuing mechanism and it is invisible from WebAudio's perspective. On the other hand, |oncomplete| from OAC uses the main thread task scheduler. IIUC these two async systems are not coordinated with each other, so the order of execution is not guaranteed to be deterministic.

One approach you can do is signaling AudioWorkletProcessor via MessagePort when the asset loading is completed. It is simple and gives you full control of execution order.

This is my initial thought on this issue, but will take another deep look after 8/18.

@hongchan
I would resist on having the same behaviour on both rendering mechanisms. It feels odd to change code to render things offline. I will probably not be the only person who will run into this situation.

I think it's the other way around. The code for both context types should be using the pattern that I described in #3.

Although somehow it might have worked out for the realtime AudioContext (because its slow start-up time compared to the OfflineAuiodContext), but it maybe possible to see the different behavior on the other device or OS. (e.g. A testing infra that uses a fake audio device - it should be faster to boot up than the actual audio device)

The only way to solve this problem without workaround/hack is to unify message queue between MessagePort and the event queue in the main thread, and I don't think it is a trivial problem.

Perhaps this can be approached via spec change as well, but I am quite uncertain about a path forward.

You're welcome to file an issue against the spec if necessary, and also let's keep this issue open for the further discussion.

Per #6; this might be worthy of spec discussion.