-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify which task source is used #2095
Comments
I think this is covered in https://webaudio.github.io/web-audio-api/#control-thread-and-rendering-thread.
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. |
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). |
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? |
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. |
Most of "queue a task" instances are for:
These are not timing critical, so using the media element task source seems sensible. I'll write up a PR. |
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
The text was updated successfully, but these errors were encountered: