Specify which task source is used

[rniwa]

The current specification doesn't specify which task source is used whenever queuing a task.

It seems like we may want to use the media element event task source here?

Related: #2008

[hoch]

I think this is covered in https://webaudio.github.io/web-audio-api/#control-thread-and-rendering-thread.

Each AudioContext has a single control message queue that is a list of control messages that are operations running on the rendering thread.
Queuing a control message means adding the message to the end of the control message queue of an BaseAudioContext.

Using the media element event task source seems wrong when there's no shared infrastructure between the media element and the audio context. If a task source is absolutely necessary, we can consider adding "web audio task source" or something similar.

I suggest that we close this.

[rniwa]

I think this is covered in https://webaudio.github.io/web-audio-api/#control-thread-and-rendering-thread.

Each AudioContext has a single control message queue that is a list of control messages that are operations running on the rendering thread.
Queuing a control message means adding the message to the end of the control message queue of an BaseAudioContext.

Using the media element event task source seems wrong when there's no shared infrastructure between the media element and the audio context. If a task source is absolutely necessary, we can consider adding "web audio task source" or something similar.

That doesn't clarify what happens when the spec enqueues a task, for example, in https://webaudio.github.io/web-audio-api/#dom-baseaudiocontext-decodeaudiodata. Any spec text which uses enqueue a task is ambiguous without specifying which task source is used. These are different from messages scheduled on control message queues because they're to be dispatched on the context objects (e.g. in the main thread where the rest of DOM API code runs).

[hoch]

The Chromium implementation uses the main thread task runner for this purpose, but the notion of task source doesn't seem to be fully implemented. So I don't have a strong opinion on this, but taking advantage of what already exists makes sense to me.

But does it mean that we have to replace any instance of "queue a task (against the main thread)" with "queue a media element task"?

@padenot What's your thought on this?

[rniwa]

The Chromium implementation uses the main thread task runner for this purpose, but the notion of task source doesn't seem to be fully implemented. So I don't have a strong opinion on this, but taking advantage of what already exists makes sense to me.

But does it mean that we have to replace any instance of "queue a task (against the main thread)" with "queue a media element task"?

Yeah, or some other task source. Note that things in different task sources could change orders so if you do create a new task source, it would mean that tasked scheduled with the media element task source can end up execute out-of-order with tasks scheduled with whatever task source AudioContext ends up using.

[hoch]

Most of "queue a task" instances are for:

• Reporting errors to the main thread
• Changing the BaseAudioContext state
• Rejecting/resolving promises
• Firing events
• Creating AudioWorklet

These are not timing critical, so using the media element task source seems sensible. I'll write up a PR.