Skip to content
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

WAM: AudioWorklet setup sub optimal #2

Closed
olilarkin opened this issue Sep 13, 2018 · 7 comments
Closed

WAM: AudioWorklet setup sub optimal #2

olilarkin opened this issue Sep 13, 2018 · 7 comments

Comments

@olilarkin
Copy link
Member

There are numerous TODOs: in IPlugWAM.cpp that should be reworked for shared array buffer. In fact significant reworking should be done to use the "powerhouse" design pattern described here:

https://developers.google.com/web/updates/2018/06/audio-worklet-design-pattern#webaudio_powerhouse_audioworklet_and_sharedarraybuffer

https://developers.google.com/web/updates/2018/06/audio-worklet-design-pattern

https://github.com/GoogleChromeLabs/web-audio-samples/tree/gh-pages/audio-worklet/design-pattern

https://github.com/olilarkin/wdl-ol-private/blob/iplugquake/IPlug/WEB/IPlugWAM.cpp#L72

@jariseon
Copy link

jariseon commented Sep 13, 2018

would it be possible to have option whether to use "standard" AWP (where DSP is rendered in audio thread) or "powerhouse" (where DSP is rendered in Worker) implementation ?

i think powerhouse has definite use cases (like sample streaming from a virtual file system), but my concern is that since worker thread has lower priority than audio thread, it might be affected by what is going on in main thread. Also, SABs introduce latency (in chrome this is one buffer, in Firefox it at least used to be > 1 buffer) which needs to be compensated. edit: could also be because of worker thread priorities differ in browsers, might not be result of different SAB latencies.

@olilarkin
Copy link
Member Author

i guess what really needs to be done is to profile the current implementation. I currently have this hack, which is not right and the main thing i want to fix..., how do you think I could have an equivalent of OnIdle() on the main thread in AWP

@olilarkin
Copy link
Member Author

in answer to your question it may well be possible... need to experiment with this stuff

@jariseon
Copy link

iiuc you want to inform main thread that AWP is idle? AWP used to have state member and a notification message from AWP -> AWN. it was removed from spec, can't remember why that was, but i guess one workaround option is to call postMessage("set", "state", "idle") to notify the main thread Controller. And post another message when state changes, i.e., not for each buffer. Another way is to use a SAB, but then you'd need to poll in main thread.

@olilarkin
Copy link
Member Author

OnIdle() is a regular poll on the main thread. Not sure how to set that up within AudioWorkletGlobalScope

@jariseon
Copy link

right, so host calls OnIdle() ? Web Audio API calls AWP periodically: first it checks if there are any messages, and if so, it invokes AWP.port.onmessage() for each message from main thread. right after that it invokes AWP.process(). currently there's only one thread in AudioWorkletGlobalScope, so it is impossible to do any processing between onmessage and process calls.

unless setTimeout is available in AWGS, but even if it is, it might not be a good idea to steal processing time from other AWPs.

@olilarkin
Copy link
Member Author

closing this. may reopen in the future to provide powerhouse pattern as an option

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants