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

Re: New name for "AudioWorker"

From: Alex Russell <slightlyoff@google.com>
Date: Wed, 7 Oct 2015 11:34:53 -0700
Message-ID: <CANr5HFXO7n5i4CnxOhPQtbVw-b_74ppaeaRCVmp-=XUkKNnJuQ@mail.gmail.com>
To: Paul Adenot <padenot@mozilla.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>
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 Wednesday, 7 October 2015 18:35:50 UTC

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