W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2016

Responses to AudioWorklet proposal

From: Joe Berkovitz <joe@noteflight.com>
Date: Thu, 5 May 2016 11:38:47 -0400
Message-ID: <CA+ojG-aG5B5ST9XnZeNCvN_-Etz9qHqaT966R9Hw4yJ2=1w+Ng@mail.gmail.com>
To: Audio Working Group <public-audio@w3.org>
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

- It looks as though you are suggesting that AudioWorkletProcessor can work
with AudioParams directly, as if it was an AudioWorkletNode: (this is from

 constructor (options) {
    // Calling super() is required for AudioParam initialization.
    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
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144

"Bring music to life"
Received on Thursday, 5 May 2016 16:31:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 May 2016 16:31:20 UTC