Re: Responses to AudioWorklet proposal

Thanks for reviewing the proposal, Joe!

We have already talked about the issues in the call, but I am also posting
the response here for everyone to see our conclusion.

> We appear to have dispensed with AudioProcessEvent, and are now passing
the former event properties to the process() method as explicit arguments.
That may be OK from an architectural point of view, but in the process we
have lost the playbackTime attribute of the event, which is a really
important thing for the node to know (and was added to the event after a
good amount of discussion). At the least I think we need to restore
playbackTime, but perhaps we also talk about whether passing in a single
event in the argument is more a robust approach if we need to further
extend the information that is provided in each processing cycle. (see
https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal#idl-audioworkletglobalscope-and-audioworkletprocessor
)

AudioWorkletProcessor's process() method get directly called by the
underlying audio thread. So it is not an event anymore. Instead, we can add
playbackTime as an argument of the process method.

> It looks as though you are suggesting that AudioWorkletProcessor can work
with AudioParams directly, as if it was an AudioWorkletNode: (this is from
https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal#examples-2
)

Yes, a very good point. To address this issue, we have to consider some
`magics` in super() call. For example, super() call will do the
instantiation of AudioParam objects and initialize with given values from
AudioWorkletNode constructor. More importantly, AudioParam instances should
not be exposed in AudioWorkletGlobalScope. You only can access the
calculated arrays of AudioParam as an argument of process method. All in
all, it seems to be okay since we already have our super() doing its magic,
but I am open to other options.

> If we were to exhibit such AudioParams as direct attributes of the
AudioWorkletProcessor, they could clash with other names in the class's
namespace like sampleRate, etc. So I think one would need to have something
like this.parameters.gain.value = options.gain.

I do still need to think about introducing something like
AudioWorkletProcessInfo object for the sample rate and whatnot, but I argue
that things should be addressed as a per-process method, rather than
per-context or per-node. Perhaps making the last argument of process method
a property bag contains all the relevant information for wrangling samples.
(playbackTime, sampleRate, framesToProcess and unicorn)

-Hongchan


On Thu, May 5, 2016 at 9:32 AM Joe Berkovitz <joe@noteflight.com> wrote:

> Hi Hongchan,
>
> Thanks for the great writeup.
>
> Here are a few observations I hope to discuss on the call. I got these
> from re-reading the old AudioWorker proposal carefully and comparing.
>
> - We appear to have dispensed with AudioProcessEvent, and are now passing
> the former event properties to the process() method as explicit arguments.
> That may be OK from an architectural point of view, but in the process we
> have lost the playbackTime attribute of the event, which is a really
> important thing for the node to know (and was added to the event after a
> good amount of discussion). At the least I think we need to restore
> playbackTime, but perhaps we also talk about whether passing in a single
> event in the argument is more a robust approach if we need to further
> extend the information that is provided in each processing cycle. (see
> https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal#idl-audioworkletglobalscope-and-audioworkletprocessor
> )
>
> - It looks as though you are suggesting that AudioWorkletProcessor can
> work with AudioParams directly, as if it was an AudioWorkletNode: (this is
> from
> https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal#examples-2
> )
>
>  constructor (options) {
>     // Calling super() is required for AudioParam initialization.
>     super();
>     this.gain.value = options.gain;
>     // ....
> }
>
> In the past, actual AudioParam objects were only available on the
> main-thread side. Is this a change? It seems potentially messy to allow
> them to be manipulated from either thread.
>
> - If we were to exhibit such AudioParams as direct attributes of the
> AudioWorkletProcessor, they could clash with other names in the class's
> namespace like sampleRate, etc. So I think one would need to have something
> like this.parameters.gain.value = options.gain.
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> President
> Noteflight LLC
>
> +1 978 314 6271
>
> 49R Day Street
> Somerville MA 02144
> USA
>
> "Bring music to life"
> www.noteflight.com
>