1) Yes, this isn't a Web Worker - at least, not per AudioWorker instance, they are more of an AudioGlobalScope. The entire audio thread for an AudioContext probably *IS* a WebWorker (or at least quite similar). If we want to call it something else, as per previous discussion, make a suggestion, I'm open. CustomAudioProcessor?
2) Yeah, I'd love to use the "native can load dynamic code without glitching" metric too. My guidance from Alex and V8 team was that although this (parsing/compile on a different thread) may happen in the future in a generic way, it simply isn't possible today in the JS environment. If/when it were to happen, one could implement AudioWorkers that work that way. On Sun, Jun 21, 2015 at 3:58 PM, Paul Adenot <pade...@mozilla.com> wrote: > > On Thu, Jun 18, 2015 at 9:06 PM, Joe Berkovitz <j...@noteflight.com> wrote: > >> >> 4. AudioWorker Progress >> >> Chris has discussed issue #532 with Alex Russell of the TAG. No >> particular outcomes there but Chris has also found that there seems to be >> little prospect of having script loading and execution run in some thread >> other than the audio thread, meaning that loading up AudioWorkers will >> inevitably cause glitching as scripts are initialize. This is not a >> showstopper though: the feature is still incredibly useful and important; >> it just means that scripts should be loaded either as part of app >> initialization or while audio is quiescent. >> >> Need Paul's input on this, and determination of best way forward to >> create a reasonable definition of AudioWorker (perhaps still not a Worker, >> fundamentally) so pushed back on Needs WG Review. >> >> @padenot can you please chime on on this subject via email? >> > > > Yeah well I'm not happy about that. I'll be talking to some people this > week. Also, yes, this is not really a worker at this point. > > My current thinking is that native can load dynamic code without > glitching, so Web Audio API should be able to do the same. > > Paul. >
