W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2015

Re: [Minutes] Audio WG teleconference 18 June 2015

From: Joe Berkovitz <joe@noteflight.com>
Date: Mon, 22 Jun 2015 10:53:00 -0400
Message-ID: <CA+ojG-a9MXh3F_xpY8pfh4o3m=+c-PDZOv3jQqDJhEs75GG0Mg@mail.gmail.com>
To: Paul Adenot <padenot@mozilla.com>
Cc: Chris Wilson <cwilso@google.com>, Audio Working Group <public-audio@w3.org>
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 <padenot@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 <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.

.            .       .    .  . ...Joe

*Joe Berkovitz*

*Noteflight LLC*
49R Day Street / Somerville, MA 02144 / USA
phone: +1 978 314 6271
"Your music, everywhere"
Received on Monday, 22 June 2015 14:53:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 14:53:30 UTC