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

Re: Web Audio API questions and comments

From: Joe Turner <joe@oampo.co.uk>
Date: Thu, 21 Jun 2012 11:08:44 +0100
Message-ID: <CA+FkkmaaE5d3qvxdHU7G_+-h1FbBWPXi2ZgeZbAm5_h2WnH_Xw@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: public-audio@w3.org
Hi Chris,

On Wed, Jun 20, 2012 at 10:29 PM, Chris Rogers <crogers@google.com> wrote:
> On Wed, Jun 20, 2012 at 2:51 AM, Joe Turner <joe@oampo.co.uk> wrote:
>> Hi Chris,
>> Thanks for the response - I think you've cleared up lots of this for me.
>> On Tue, Jun 19, 2012 at 8:35 PM, Chris Rogers <crogers@google.com> wrote:
>> >
>> >
>> > On Tue, Jun 19, 2012 at 7:39 AM, Joe Turner <joe@oampo.co.uk> wrote:
>> >>
>> >>
>> >> - AudioNode cycles with JavaScriptAudioNodes
>> >>
>> >> Given that JavaScriptAudioNodes have an inherent delay built in they
>> >> should be fine to use in feedback loops as well as DelayNodes I think.
>> >>  Is this correct?
>> >
>> >
>> > I think it will be ok, although the latency of the JavaScriptAudioNode
>> > will
>> > factor into the overall delay.  There would be some limits on very small
>> > delay sizes.  But in many practical cases, this won't be an issue.
>> >
>> Yeah - can this be changed in the specification then so it won't throw
>> an exception?  I could see this being handy.
> I know we've discussed different strategies, including throwing exceptions,
> but I don't remember adding that to the spec yet.  I hope we can avoid
> dealing with exceptions in this case.

In section 4.2.2 it says "This is allowed only if there is at least
one DelayNode in the cycle or an exception will be thrown."  I think
this should read "DelayNode or JavaScriptAudioNode".

>> >>
>> >> Although a better solution may be:
>> >>
>> >> - Operator nodes, AudioParam nodes
>> >>
>> >> Can we have separate nodes for the basic mathematical operators (add,
>> >> subtract, divide, multiply and modulo), and a way of having the output
>> >> of an AudioParam as a signal?
>> >
>> >
>> > We already have add, subtract, and multiply.  You can also get many
>> > other
>> > transformations by using a WaveShaperNode.  There are probably some
>> > operations which would not be possible, but I think they would be *much*
>> > more specialized.  And in these cases a JavaScriptAudioNode could help
>> > out.
>> >
>> >
>> >>
>> >>  This would allow all the flexibility
>> >> needed for scaling, offsetting and combining signals in order to
>> >> control parameters.
>> >
>> >
>> > I think we already have these with the built-in mixing and the
>> > AudioGainNode, etc.
>> >
>> >>
>> >>  I know a bit of trickery can make stuff like this
>> >> possible at the moment, and it's trivial to implement in JavaScript,
>> >> but it seems like core functionality to me.
>> >
>> >
>> > I'm open to suggestions, but think many of the things you've mentioned
>> > are
>> > already possible.
>> Here's where I tend to disagree a little.  It seems unintuitive to me
>> to be doing audio maths using the WaveShaperNode.  For example, say I
>> want to get the reciprocal of a signal.  In order to do this I have
>> two options.  One is to write a JavaScriptAudioNode - this is trivial,
>> but now my Synth has four times the latency it had before.  My other
>> option is to create a Float32Array and fill it with a 1/x curve then
>> make a WaveShaperNode from this.  This, I would argue, is:
>> a) Non-trivial - I always get the maths with the indices wrong the
>> first time when creating lookup tables (although that might just be
>> me...)
>> b) Gives a 'worse' result - we are using a lookup table rather than
>> doing the maths directly
>> c) Non-obvious - the specification says that the WaveShaperNode is for
>> creating "non-linear distortion effects", which is not what I'm trying
>> to do
>> I can see that a 20 line JavaScript library would sort this out (and
>> would be the first thing I included in any Web Audio API project), but
>> making it non-trivial to do maths on the audio stream, create
>> constants etc. for the sake of reducing the number of nodes by one or
>> two seems like a strange decision.
> I agree with you for a 1/x curve, and other less commonly used curves.  But
> the DC-offset, addition, subtraction, and multiplication can all be done
> without a WaveShaperNode.  And these are the ones which I thought would
> cover a large number of the common cases.  Division is very much less used,
> so I didn't think to define a node specially for it.

Perhaps you're right about division - I am struggling to think of
having ever used it in this context.  It maybe isn't the right place,
but would it be possible to have a note in the spec which makes it
clear that the WaveShaperNode is also be used for this sort of thing?
I'm a bit worried that there would be an issue of discoverability

I think my last question on this is what is the recommended way of
creating the equivalent to variables?  So say I wanted to add a dc
offset of 50 to a signal, am I expected to use a JavaScriptAudioNode
which outputs 50s, waveshape an oscillator so it outputs 1 and use an
AudioGainNode to scale it up to 50, or do something else clever which
I haven't thought of?  I still think a node which just outputs the
value of an AudioParam would be nicer than either of these two

Received on Thursday, 21 June 2012 10:09:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:05 UTC