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

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

From: Joseph Berkovitz <joe@noteflight.com>
Date: Fri, 19 Sep 2014 12:33:04 -0400
Cc: Olivier Thereaux <olivier.thereaux@bbc.co.uk>, Audio WG <public-audio@w3.org>
Message-Id: <74DFE079-C406-48AE-BF14-0A0AEC31222F@noteflight.com>
To: Chris Wilson <cwilso@google.com>
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?


.            .       .    .  . ...Joe

Joe Berkovitz

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
"Your music, everywhere"
Received on Friday, 19 September 2014 16:33:34 UTC

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