The only possibility I see currently is to just slave the main loop to the AudioWorklet processing callback and blindly hope that it is able to hit the scheduli

The only possibility I see currently is to just slave the main loop to the AudioWorklet processing callback and blindly hope that it is able to hit the scheduling deadlines. The current native app (say, in Linux) has both a scripting language and a DSP "dataflowy" language that can run and interact in the same process. This means the user can manually (or programmatically) turn on DSP processing opportunistically. However, with the Web Audio idea above this means that the software I'm porting must be calculating its DSP graph from the AudioWorklet callback at all times for the software to work at all. If I suspend audio computation in the parent script time would no longer move forward. Or I'd have to switch to having the DOM poll the worker-- feeding it the current time-- which I'm just guessing would kill performance.