Fwd: [WebAudio/web-audio-api] Add AudioWorklet section (#869)

Hi Hongchan,

It seems as though we are very close to absorbing this feedback from
Domenic into the spec. The above two issues still need resolution but the
path seems clear.

Time is starting to run out prior to TPAC. How close are we to having the
TAG feedback that Paul and Ray wanted? I recall that you wanted Alex
Russell to give some feedback also.

It would be great if we could have all AudioWorklet feedback in hand and a
plan for responding to it for tomorrow's call.

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

---------- Forwarded message ----------
From: Domenic Denicola <notifications@github.com>
Date: Mon, Aug 8, 2016 at 11:31 PM
Subject: Re: [WebAudio/web-audio-api] Add AudioWorklet section (#869)
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Cc: Joe Berkovitz <joe@noteflight.com>, Comment <comment@noreply.github.com>


It's a subclass derived from AudioWorkletProcessor. This concept of
'two-objects-in-different-threads' is quite new to the world, even for the
Worklet. However, we need two objects that represents the 'main thread
interface' and the 'audio thread interface' respectively. It might be nice
to have your perspective on this because the discussion has been going on
only inside of WG.

Two objects in different threads seem fine. The problem is that the spec as
written creates the objects and then does nothing with them. This means
that they can be garbage collected immediately. You need to specify where
to store them and what holds references to them and uses them later.

Hmm. This is surprising because this process method is the core of
AudioWorkletProcessor. As you pointed this must be implemented by the
subclass. If you don't, you get the silence out of this node. (or should we
throw? this needs to be defined too.) How can we capture the interface of
this method if we cannot put it on the IDL?

The IDL is just instructions for how bindings generators in implementations
should perform conversions and create APIs. It doesn't have anything to do
with the web developer-facing interface and requirements for using the API.
That is better documented in, well, documentation, not in normative
interface definition language.

Since the implementation should not have a process method, it must not
appear in the IDL.