Re: New name for "AudioWorker"

How does it interact with other nodes in the AudioContext? Apparently you
cannot synchronize 'off-audio-thread' processors with 'in-audio-thread'
nodes. (That's exactly what we have in the name of ScriptProcessorNode
currently.)

This 'Processor' is basically a custom AudioNode, and it is supposed to be
a part of the audiograph. Right? If the 'off-audio-thread' Processor node
can't interact with the regular audio nodes, why do we need it? Can't we
just use OfflineAudioContext for that purpose?

On Wed, Oct 7, 2015 at 10:34 AM Paul Adenot <padenot@mozilla.com> wrote:

> Yes that's a non-negociable requirement for the Web Audio API, and that's
> what Ian's first point and third points allow (if I'm not mistaken). Once
> we have this capability, we can create new threads and all.
>
> Paul.
>
> On Wed, Oct 7, 2015 at 7:28 PM, Chris Wilson <cwilso@google.com> wrote:
>
>> I have a strong desire that we spec this with synchronicity in the audio
>> thread; that is, the nodes all run in the same thread, and would have to
>> (and should be able to) fork other threads if necessary for processing
>> purposes.
>>
>> On Wed, Oct 7, 2015 at 10:24 AM, Paul Adenot <padenot@mozilla.com> wrote:
>>
>>> Also I was writing a separate draft to spec this, but I'll hold off for
>>> now.
>>>
>>> Paul.
>>>
>>> On Wed, Oct 7, 2015 at 7:20 PM, Paul Adenot <padenot@mozilla.com> wrote:
>>>
>>>> On Wed, Oct 7, 2015 at 7:12 PM, Ian Kilpatrick <
>>>> ikilpatrick@chromium.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Houdini is attempting to add extension points into the rendering
>>>>> pipeline of browsers. Because of this we need properties similar to what is
>>>>> required for AudioWorker (at the moment we've called it IsolatedWorker,
>>>>> fine with changing the name to IsolatedProcessor or something
>>>>> <bikeshed-here>).
>>>>>
>>>>> I'm currently writing a draft of the spec at the moment and should
>>>>> appear here (https://drafts.css-houdini.org/isolated-workers/) at the
>>>>> end of the week.
>>>>>
>>>>> It will be based on the strawperson discussed at Houdini Paris F2F. (
>>>>> http://bfgeek.com/css-houdini-drafts/css-script-api/Overview.html).
>>>>>
>>>>> A few properties that we'd like from this spec:
>>>>>  - Thread-agnostic - that is, it does not define on which thread this
>>>>> is run, may share a thread with something else, i.e. main document context.
>>>>>  - Subset of APIs - remove network request APIs etc.
>>>>>
>>>>
>>>> I'd rather have this opt-in (you pick the APIs you want) than opt-out
>>>> (you remove some APIs).
>>>>
>>>>
>>>> The rest is what we need indeed.
>>>>
>>>> Paul.
>>>>
>>>>
>>>>>  - Hook based - APIs will be reached by registering callbacks on
>>>>> GlobalScope, e.g. registerPaint() not event based.
>>>>>  - Life-cycle - can be created/destroyed at defined points in time.
>>>>> Similar to ServiceWorker.
>>>>>
>>>>
>>>>> Additionally we've observed that javascript implementations have a
>>>>> high memory overhead per javascript context. We believe we want to limit
>>>>> the number created, so similar to the main javascript execution context,
>>>>> code shares a single javascript execution context. Details of this is
>>>>> probably better discussed one there is a proposal.
>>>>>
>>>>> Ian
>>>>>
>>>>> On Wed, Oct 7, 2015 at 9:32 AM, Chris Wilson <cwilso@google.com>
>>>>> wrote:
>>>>>
>>>>>> I'm actually off-the-cuff against trying to boil the ocean of the
>>>>>> general pattern.  This is pretty specific - the new thing , runs *IN*
>>>>>> something that can be a Worker-like process, but they're expected to share
>>>>>> the process.  The thing you can instantiate lots of (runtime contexts?) run
>>>>>> inside that process.
>>>>>>
>>>>>> I was expecting we would rename AW to CustomAudioProcessor, still
>>>>>> define them as running inside a Worker (and define how that Worker-sharing
>>>>>> works), and use Worker messaging.  That seemed like the shortest path to
>>>>>> success.
>>>>>>
>>>>>> On Wed, Oct 7, 2015 at 9:16 AM, Hongchan Choi <hongchan@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Nothing forces workers to be heavy weight, but doesn't it have the
>>>>>>> assumption that it runs on its own thread? What we want is to be able to
>>>>>>> throw JS code into VM that runs on the audio thread.
>>>>>>>
>>>>>>> Perhaps we can break that assumption, and propose a new type of
>>>>>>> Worker.
>>>>>>>
>>>>>>> On Wed, Oct 7, 2015 at 9:09 AM Alex Russell <slightlyoff@google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Why isn't this thing a worker? What forces workers to be
>>>>>>>> heavyweight?
>>>>>>>>
>>>>>>>> Also, would be good to align with the Houdini folks on this as
>>>>>>>> they're proposing similar things in the rendering and compositing space.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> On 7 Oct 2015 7:52 a.m., "Paul Adenot" <padenot@mozilla.com> wrote:
>>>>>>>>
>>>>>>>>> We need to decide for a new name for something that:
>>>>>>>>>
>>>>>>>>> - Runs off-main-thread
>>>>>>>>> - Has access to a very limited set of APIs
>>>>>>>>> - Can be instantiated a lot of times in the same document (much
>>>>>>>>> more than Workers can or would)
>>>>>>>>> - Is specialized to one domain (audio, video, etc.)
>>>>>>>>> - ... ?
>>>>>>>>>
>>>>>>>>> It is likely that we would be the first group to spec something
>>>>>>>>> like this, but it would be used by other groups (layout people, video/image
>>>>>>>>> processing folks, etc.). We need something that is not too tied to audio,
>>>>>>>>> or can be adapted. I propose "Processor", which conveys the meaning of
>>>>>>>>> taking something as input, applying a transformation, and outputting it.
>>>>>>>>> I'm very open to suggestions though, this is merely to get the ball rolling.
>>>>>>>>>
>>>>>>>>> Thoughts ?
>>>>>>>>> Paul.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>