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

Hi Chris.

Just to add a little more clarity on my remarks at the meeting...

On Sep 19, 2014, at 11:55 AM, Chris Wilson <cwilso@google.com> wrote:
> Ongoing. Joe suggested two issues were still unresolved: one relates to the extent to which an audioworkernode can fully implement the behaviour of a native node;
> 
> 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().

I wonder if everyone (including developers) understands that “behavior” in the above definition of the design constraint means functionality, rather than interface. If it’s just functionality, then fine: we’re done.  But the introduction of dynamic AudioParams was a large step towards supporting full native-node interfaces, and perhaps it’s raising an implied question of how far V1 is intended to go towards the “interface” idea of native-node emulation.

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.

If I missed something or am just plain wrong, please correct me.

>  
> the other (see https://github.com/WebAudio/web-audio-api/issues/69) is related to OfflineAudioContext.
> 
> That issue is with ScriptProcessors.  Audio Workers should work in an OfflineAudioContext with no issues.

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.

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?

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"