Responses to AudioWorklet proposal

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