This is good dialogue -- it would be great if we could be at (or very close to) a more wrapped-up patch to the spec by the date of the next telcon.
On Mon, Jun 22, 2015 at 10:25 AM, Paul Adenot <pade...@mozilla.com> wrote: > Oh I thought it was a spec issue, for the parse/compile off-main-thread > thing. I'm pretty sure Gecko and IE do off-main-thread parse and compile > already, so that might not be an issue. > > Last I checked, the Worker spec was quite explicit about parsing/compiling > script on the same thread as the worker. I'll ask questions to make sure > we're reading and understanding the right thing. > > Also yes, I'll try to think about a name. > > Paul. > > On Mon, Jun 22, 2015 at 12:00 AM, Chris Wilson <cwi...@google.com> wrote: > >> 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. >>> >> >> > -- . . . . . ...Joe *Joe Berkovitz* President *Noteflight LLC* 49R Day Street / Somerville, MA 02144 / USA phone: +1 978 314 6271 www.noteflight.com "Your music, everywhere"
