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

Yes, I'm fine with landing what we have given the feedback that we've
received. It's the best thing to do.

Can anyone (including me) help with the above feedback points?

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Wed, Aug 10, 2016 at 1:12 PM, Hongchan Choi <hongchan@google.com> wrote:

> Hello Joe,
>
> I haven't gotten the response from Alex yet and am working on the
> following points:
>
> - Rename registerAudioWorkletProcessor() to registerProcessor().
> - Define where 'AudioWorkletDefinition' gets stored.
> - Specify how the message passing system works for AudioWorklet: I think
> we can point the processing model.
> - Specify an algorithm that how the key-value pairs get parsed into
> corresponding AudioParams in the audio worklet processor.
> - AudioWorkletProcessor::process() cannot be specified in the IDL since
> it is not a part of the vendor implementation.
> - Write the introduction section for AudioWorklet preferably with an
> example.
>
> The current PR is too bloated with too many things (loading time is huge),
> so I would say we land what we have first and fiddle it over next few
> weeks. Once we land the current PR,  we can break down the to-do items and
> collaborate easily.
>
> Best,
> Hongchan
>
>
> On Wed, Aug 10, 2016 at 8:43 AM Joe Berkovitz <joe@noteflight.com> wrote:
>
>> 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.
>>
>>
>>