Intent to Implement and Ship: WebAudio ConstantSourceNode

Raymond Toy

unread,

Sep 13, 2016, 11:49:39 AM9/13/16

to blink-dev

Contact emails

rt...@chromium.org, hong...@chromium.org

Spec

https://webaudio.github.io/web-audio-api/

Summary

Adds a new ConstantSourceNode that produces a constant output. However, it also has an AudioParam to allow automation of the output value, and can therefore serve as a "constructible AudioParam".

Motivation

Developers want a "constructible" AudioParam node that can be used to attach automations to and which can then be fed as the input to other nodes or be connected to other AudioParams.

This can be done today using an AudioBufferSourceNode, but the usage is rather awkward. Instead, a ConstantSourceNode will be provided whose nominal output is constant but has an AudioParam attribute that can control the node output. A constant output node is valuable in its own right.

One minor current issue: Should we also add a createConstantSource factory method? For consistency with the existing v1 nodes, the factory method is included, but this isn't really necessary.

Interoperability and Compatibility Risk

Minimal risk. We fully expect other browsers to implement this. The node is quite useful in itself.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

http://crbug.com/644438

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5647701588836352

Requesting approval to ship?

Yes

Philip Jägenstedt

unread,

Sep 14, 2016, 10:01:56 AM9/14/16

to Raymond Toy, blink-dev

Is something blocking the merging of the spec PR? It's much easier to follow a link than to clone the spec repo :)

Raymond Toy

unread,

Sep 14, 2016, 1:34:02 PM9/14/16

to Philip Jägenstedt, blink-dev

I think the only thing blocking is a "real" lgtm and a decision on whether we want the factory method.

If everyone wants to wait for the merge, that's fine with me. I can ping this when it's merged.

Raymond Toy

unread,

Sep 14, 2016, 2:00:54 PM9/14/16

to Philip Jägenstedt, blink-dev

This might be useful: https://rawgit.com/rtoy/web-audio-api/6907f985b6318da6f82f3e7fd71c73d39ace495c/index.html#ConstantSourceNode

Rick Byers

unread,

Sep 14, 2016, 2:58:28 PM9/14/16

to Raymond Toy, Philip Jägenstedt, blink-dev

On Wed, Sep 14, 2016 at 2:00 PM, 'Raymond Toy' via blink-dev <blin...@chromium.org> wrote:

This might be useful: https://rawgit.com/rtoy/web-audio-api/6907f985b6318da6f82f3e7fd71c73d39ace495c/index.html#ConstantSourceNode

On Wed, Sep 14, 2016 at 10:33 AM, Raymond Toy <rt...@google.com> wrote:
I think the only thing blocking is a "real" lgtm and a decision on whether we want the factory method.

If everyone wants to wait for the merge, that's fine with me. I can ping this when it's merged.

In general we rely on the status of a spec in trunk as a minimal indication that there's some consensus between browser vendors that they believe the API is reasonable. We definitely don't want to risk sending the impression that we're not interested in hearing / responding to feedback in the spec change review process (kind of a touchy subject already since some people would prefer we wait all the way for a spec to reach 'REC' status before shipping <grin>).

So if there's not a compelling reason to rush this case, I'd personally prefer we wait for the PR to land.

Raymond Toy

unread,

Sep 28, 2016, 11:42:00 AM9/28/16

to Rick Byers, Philip Jägenstedt, blink-dev

The changes has landed in the spec and is described in https://webaudio.github.io/web-audio-api/#ConstantSourceNode

Rick Byers

unread,

Sep 28, 2016, 11:51:11 AM9/28/16

to Raymond Toy, Philip Jägenstedt, blink-dev

LGTM1.

Looks like there was some discussion between vendors at TPAC, and at least the Mozilla person who reviewed the PR was happy with the API, right?

Raymond Toy

unread,

Sep 28, 2016, 2:59:50 PM9/28/16

to Rick Byers, Philip Jägenstedt, blink-dev

Yes, the Mozilla rep was ok with the node, with a few minor changes. We will keep the factory method for consistency, and the AudioParam is named offset (not value or source or sourceValue), and its default value is 1.

Unfortunately the Microsoft rep was not there. (No Apple rep has shown up in quite a long time.)

Philip Jägenstedt

unread,

Sep 28, 2016, 3:39:11 PM9/28/16

to Raymond Toy, Rick Byers, blink-dev

Why does ConstantSourceNode need start and stop methods? Is it not redundant with setValueAtTime and friends on AudioParam?

Raymond Toy

unread,

Sep 29, 2016, 1:09:06 PM9/29/16

to Philip Jägenstedt, Rick Byers, blink-dev

It's a source node like AudioBufferSourceNode and OscillatorNode. Having start and stop methods allows you to precisely start and stop the node. Yes, this can be effectively achieved by automating the AudioParam, but then you can't have the fire-and-forget feature of the other source nodes. You have to hold a reference until you're finished and disconnect it manually and drop the reference. With the stop method, you can drop the reference after scheduling the start and stop, and the node will play as scheduled and automatically disconnect itself when done.

Philip Jägenstedt

unread,

Sep 29, 2016, 1:42:11 PM9/29/16

to Raymond Toy, Rick Byers, blink-dev

Makes sense, LGTM2!

Chris Harrelson

unread,

Sep 29, 2016, 1:44:02 PM9/29/16

to Philip Jägenstedt, Raymond Toy, Rick Byers, blink-dev

LGTM3

Makes sense, LGTM2!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Reply all

Reply to author

Forward