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

On Fri, Sep 19, 2014 at 9:33 AM, Joseph Berkovitz <joe@noteflight.com>
wrote:

> 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.