W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2015

Re: New name for "AudioWorker"

From: Paul Adenot <padenot@mozilla.com>
Date: Thu, 8 Oct 2015 15:17:13 +0200
Message-ID: <CANWt0WqUJPjOWuN9UTO-on4FmOcF+LpXT1uDBH+tfzrD6iuv9Q@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: Chris Wilson <cwilso@google.com>, Hongchan Choi <hongchan@google.com>, "public-audio@w3.org Group" <public-audio@w3.org>, Shane Stephens <shanestephens@google.com>, Ian Vollick <vollick@chromium.org>, Ian Kilpatrick <ikilpatrick@google.com>
"Not run continuously", as in, you don't decide when it runs and when it
does not. You can't wake it up. This is not compatible with event loops as
spec-ced today.

In any case, the current worker infrastructure is way to heavy for any of
the applications we want here.

Paul.





On Wed, Oct 7, 2015 at 8:34 PM, Alex Russell <slightlyoff@google.com> wrote:

> On Wed, Oct 7, 2015 at 9:48 AM, Paul Adenot <padenot@mozilla.com> wrote:
>
>> On Wed, Oct 7, 2015 at 6:32 PM, 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.
>>>
>>
>> It might look like a worker-like process, but is actually pretty
>> different: it does not run continuously, for starters.
>>
>
> We have a variant of this in both Shared Worker and Service Worker. Why is
> this different than those?
>
>
>> 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.
>>>
>>
>> Yes, but we've clearly shown that this cannot work, because workers bring
>> in a model and APIs that can't work for us.
>>
>> We have the same model than what the CSS and video folk need (something
>> happens on some thread, we run a bit of script on this thread). We also
>> need light input from ECMA so we don't redefine too much things. I think
>> it's the right way to do it to avoid wasting other people's time and have
>> solid spec and implementations.
>>
>> Paul.
>>
>>
>>>
>>> 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.
>>>>>>
>>>>>
>>>
>>
>
Received on Thursday, 8 October 2015 13:18:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 18 December 2015 09:00:35 UTC