W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2014

Re: [minutes] Audio WG teleconference, 2014-09-18

From: Chris Wilson <cwilso@google.com>
Date: Fri, 19 Sep 2014 10:07:02 -0700
Message-ID: <CAJK2wqX+8QLF27Y-oMr6o0eiF+_qot_1UntrrDFf3vi42yws-A@mail.gmail.com>
To: Joseph Berkovitz <joe@noteflight.com>
Cc: Olivier Thereaux <olivier.thereaux@bbc.co.uk>, Audio WG <public-audio@w3.org>
On Fri, Sep 19, 2014 at 9:33 AM, Joseph Berkovitz <joe@noteflight.com>

> How so?  My design constraint in creating Audio Workers was essentially
> "they should be able to duplicate (modulo CPU impact) the behavior of a
> natively implemented node.”
> I think that workers under your proposal can indeed fully duplicate
> native-node *functionality*, but cannot duplicate every aspect of a
> native-node *interface*. Specifically, functions and non-AudioParam
> attributes cannot be exposed by an AudioWorkerNode; postMessage() must be
> used instead to implement these things by messaging the underlying worker
> (and possibly waiting for a response message before delivering a result to
> a main-thread callback). Examples include OscillatorNode.type and
> OscillatorNode.setPeriodicWave().

Actually, not true - in this case, you can easily still expose
non-AudioParam attributes and methods on the AudioWorkerNode; you just then
need to hook them up (via getters and setters on the attribute) to a
postMessage implementation.  Yes, postMessage is in the path; that doesn't
mean the user has to see it as "postMessage( {"type":"sawtooth"} );"

> Personally I am on the fence about this. But I suspect that API developers
> may not realize that to implement the rather fundamental idea of “method on
> a scripted node delivering some result” they'll have to implement a little
> postMessage-based RPC of their own.

I think most developers won't need to understand this; they'll be consumers
of it.  Most library implementers will understand it, though.

I agree, they should work — but it would be good to walk through the extant
> OfflineAudioContext issues w/r/t ScriptProcessorNodes and verify that they
> are all moot. I would bet they are all fine and I cannot think of anything
> broken offhand.

I'd have to re-discuss with Paul what Firefox does with SPNs in OACs, but
the fundamental problem with them in Blink/webkit is that they're
asynchronous, and they don't hang waiting for responses.  That concern is
completely moot in workers.

> Also I have a sense that thinking about AudioWorkers through an offline
> lens may also shed light on how we can best tighten up the spec on what a
> scripted node can expect re timing and sequencing of onaudioprocess
> callbacks, both online and offline. That tightening-up is something you’ve
> said you want to do and I share your sense that it’s important. Perhaps
> that’s yet a third TBD for the AudioWorker spec change? What do you think?

Well, now I'm on the fence, because I think it's sane to write a section
that illustrates to users how the audio processing is constructed, but if
that were normative, it would likely remove your freedom to come up with
some way to parallelize.
Received on Friday, 19 September 2014 17:07:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:14 UTC