Re: [Minutes] Audio WG teleconference 18 June 2015

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 <cwilso@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 <padenot@mozilla.com> wrote:
>
>>
>> On Thu, Jun 18, 2015 at 9:06 PM, Joe Berkovitz <joe@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.
>>
>
>