-
Notifications
You must be signed in to change notification settings - Fork 55
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
Make MIDIAccess transferable and exposed to workers #256
base: gh-pages
Are you sure you want to change the base?
Make MIDIAccess transferable and exposed to workers #256
Conversation
I think at this point it's more useful in Worklet (so it's exposed in AudioWorklet) than worker. |
We've discussed this at TPAC and concluded this is best done by authors, like it is in native code. |
I'm wondering if we should make it transfer-only, and refuse regular cloning. I think it would simplify things somewhat. |
Re: @cwilso - What @padenot stated above means that the group believes this works better with Worker and SAB. Also the feature set in the WorkletGlobalScope is intentionally minimum, so we want to make sure all interfaces used by Web MIDI are properly supported by it. If incoming MIDI events are bound to AWGS, we'll see a lot of bursty actions in the performance of audio callback. Creating new events is "allocation", and we don't want to do that on the RT audio thread.
@padenot Do you have any example of that? @mjwilson-google Have we confirmed that all the interfaces in the Web MIDI API are supported in the WorkerGlobalScope? I am assuming it does, but it doesn't hurt to check. :) |
@hoch hmm, yeah, you're right, makes sense. I retract my previous statement. :) |
@hoch I don't know how to confirm that the interfaces are supported in WorkerGlobalScope. How do we do that? |
From the spec(https://webaudio.github.io/web-midi-api), I see these interfaces: 5.1 MIDIInputMap Interface This PR only has a change for MIDIAccess, so it needs to be expanded to add the Worker exposure (e.g. [Exposed=Worker]) to all the interfaces. |
Done. Is it fine to keep Transferable only on the MIDIAccess interface? |
In terms of developer ergonomics, I think it's fine. The author performs the request from the main thread. This deals with the all the permission business. The author then transfers the We can also decide to allow sending ports and such to the worker, but I think I like that style less. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@padenot How does the current state look? Do you want to explore making the object transfer-only? Would the way to do that be to mark it as non-serializable, to disable cloning? We will need a follow-up PR to further define the behavior when transferred before closing the linked issue. |
This is to fix #99.
Some things to note: