Re: Comments on AudioWorklet examples

Great! I am glad we found the source of confusion.

Yes, I think the instantiation procedure of AWN/AWP must be identical to
the one of regular AudioNodes. In one way or another, the Web Audio API
implementation has two layers for a node: the main thread representation
and the small surface exposed to the audio render thread. Everything
belongs to the main thread is 'deferrable', while the `process()` method is
non-blockable and accessed by the audio thread. The instantiation of a node
falls into the former.

Once again - I really want to avoid defining a custom node by writing a
pair of scripts, but perhaps that's the only sane way of resolving this. We
need to discuss this at least few more days. I don't think I can come up
with a solid alternative by tomorrow's call.

Thanks for the insight, Joe - it's been really helpful for me!

-Hongchan

On Wed, Jun 1, 2016 at 3:05 PM Joe Berkovitz <joe@noteflight.com> wrote:

> Hi Hongchan,
>
> You replied privately to me -- I'm CCing the group on this response since
> it feels like we're just continuing the same thread that's of interest to
> everyone, which I hope is OK.
>
>
>> If we are only seeking the functionality of API design, the
>> initialization or the visibility should not be an issue at all. We can be
>> as explicit and verbose as possible (whichever you want to crack this down
>> - subclassing, another main thread registration). However, I would like us
>> to spend more time to make the structure concise and intuitive, rather than
>> tossing the burden of complexity to developers. This is me being hand-wavy,
>> but hope you can agree with this.
>>
>
> I totally like intuitive and concise. I also think that developers
> creating custom nodes will be pleased to wrap an AudioWN in their own nodes
> to hide the "workletness". But I think we can have it both ways without
> sacrificing anything good.
>
> Maybe we just need to talk this through on tomorrow's call!
>
>
>> > This class is defined, registered and instantiated on the audio
>> thread.
>>
>> This is not true. The instantiation happens on the main thread. (even for
>> regular audio nodes) Only `process()` method runs on the audio thread. I
>> guess this was the point of confusion and I am glad you raised the
>> question. I think we definitely have more to think about.
>>
>
> I was talking about AudioWorkletProcessor instantiation, not
> AudioWorkletNodes, just making sure.
>
> This is big news to me (if I understand correctly). And, actually, good
> news. So AudioWorkletProcessors (not Nodes) are instantiated on the main
> thread, but in a special global scope? I guess that would resolve this
> issue I'm having with exposing parameters right after instantiation. That
> means that when you synchronously create an Node, the Processor can also be
> created synchronously (and its param descriptors examined) before the Node
> is handed back.
>
> My misunderstanding shows that there is lots of room for interpretation in
> these examples, I guess.
>
>
>> > If we want these parameters to be instantly visible on a synchronously
>> instantiated AudioWorkletNode of the corresponding kind, then param
>> descriptors must be noted at the time that the Processor is registered (by
>> calling registerAudioWorkletProcessor) and communicated back to somewhere
>> that is immediately accessible from the main thread.
>>
>> I am not sure why the param descriptors must be available at the time of
>> registration. Like I mentioned above, the instantiation should happen on
>> the main thread. So after the construction of an AWN, the parameters
>> within will be available immediately.
>>
>
> I was thinking that at least one AWP (not an AWN) had to be constructed in
> advance, in order to determine the param descriptors. But if an AWP can be
> instantiated synchronously with the construction of its corresponding AWN,
> then the problem I've been describing goes away.
>
> ...Joe
>