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

Re: Updates to Web Audio API editor's draft

From: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
Date: Wed, 9 May 2012 05:38:22 +0800
Message-Id: <02922C78-FC3C-4D0B-BAE9-4297EAF0AF82@gmail.com>
To: public-audio@w3.org
The "connect AudioNode output to AudioParam" feature is a super 
neat and welcome addition!

On fan-in -

Is fan-in up for consideration in the spec? I notice that there is no 
mention of fan-in in the spec while the node=>param fan-out support is
explicit. The WebKit source, though, indicates that fan-in support might 
be expected (https://bugs.webkit.org/show_bug.cgi?id=83610).

For an opinion, not having fan-in for an AudioParam is not a big deal 
since an AudioGainNode can always be used as a summer if one is needed ... 
sort of on the "simple things should be simple and complex
things should be possible" principle.

AudioParam -

AudioParam has automation capabilities that are re-use worthy and it
appears useful to expose the creation of AudioParams for use in 
JavascriptAudioNodes so that they can be equal citizens.
The "for later version" proposal by Jussi+Chris described in 
http://www.w3.org/2011/audio/track/issues/6 would nicely complement the 
new a-rate param support and would also serve as a mechanism
for "named inputs" to a JS node, albeit single channel ones.

Btw, if I understood it right, the current WebKit implementation is limited 
by the fact that an AudioParam needs to be *used* in a node for its values 
to update according to the timeline. Is that design a factor in not adding an 
AudioParam constructor to, say, AudioContext in the proposal?

Best,
-Kumar
Received on Tuesday, 8 May 2012 21:40:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 May 2012 21:40:58 GMT