W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2011

Re: General Notes on Web Audio API from TPAC

From: Chris Rogers <crogers@google.com>
Date: Sun, 11 Dec 2011 17:58:49 -0800
Message-ID: <CA+EzO0=qugC898Dx5Fu1UPCfexNDE661GaUO_0=rfcQBzQ+umw@mail.gmail.com>
To: Raymond Toy <rtoy@google.com>
Cc: Alistair MacDonald <al@signedon.com>, public-audio@w3.org
Those who don't care about tweaky math details can skip this message :)

On Mon, Nov 28, 2011 at 1:47 PM, Raymond Toy <rtoy@google.com> wrote:

>
>
> On Mon, Nov 28, 2011 at 11:39 AM, Alistair MacDonald <al@signedon.com>wrote:
>
>> Hi Group,
>>
>> While working with the Web Audio API at TPAC I was taking some notes. I
>> sent these to Chris Rogers and we started discussing this a few weeks back.
>>
>> Some of the technical discussion may be very useful / interesting to
>> people experimenting with the API, so I'm going to forward the thread to
>> public-audio here.
>>
>> At the bottom of the email I have attached the original notes I sent to
>> Chris.
>>
>> Comments/discussion always welcome,
>>
>>>
>>> P O S S I B L E  -  B U G S
>>> ===========================
>>>
>>>
>>>
>>> AudioParam ...RampToValueAtTime( 0, 0 )
>>> ---------------------------------------
>>>
>>> Exponential ramps do not seem to work properly when starting using
>>> "zero" values.
>>> I would expect to hear the sound ramping in from 0 or out to 0, instead
>>> the
>>> transition appears to be immediate when it reaches the given time. Much
>>> like the
>>> behavior of the setValueAtTime() method.
>>>
>>
>> This is a consequence of the math behind exponential curves.  You can
>> always have an exponentially increasing curve from
>> value1 -> value2
>>
>>
> It's not clear from the webaudio docs what an exponential ramp should do,
> but we could define the ramp to be
>
> value1 + (value2-value1)*(1-exp(-t/C))
>
> This will be an exponential ramp starting at value1 and asymptotically
> approaching value2.
>
> Two major differences:
>
>
>    - 0 is valid starting point.
>    - We never actually reach value2, but just get closer and closer.
>
> Ray
>

Hi Ray,

Sorry I should add more detail in the Web Audio spec about this.  In the
meantime, here are some comments:

 this asymptotic approach that you're describing is exactly what the
AudioParam. setTargetValueAtTime() does:
        // Exponentially approach the target value with a rate having the
given time constant.
        void setTargetValueAtTime(in float targetValue, in float time, in
float timeConstant);

But this is different
than AudioParam. exponentialRampToValueAtTime()  (exponential ramp):
        void exponentialRampToValueAtTime(in float value, in float time);

For value2 > value1:
1. exponential ramp: value increases exponentially (slowly at first, then
faster and faster - as time increases)
2. exponential approach: (setTargetValueAtTime) value increases quickly at
first, but then value changes slower and slower as
value asymptoticly approaches target value)

Both (1) and (2) have applications in audio and are a part of many computer
music languages, synthesizers, and audio processing systems.

Examples where (1) exponential ramps are especially important are playback
rates and filter frequencies.  For example, if changing the playback rate
from one octave lower to one octave higher the playback rate changes from
0.5x -> 2x.  So in order to make the pitch sound like it's increasing at a
constant rate, you need to use an exponential ramp from 0.5 -> 2.  In
another example using filter frequency, we may want to sweep a resonant
filter from 20 hertz to 2000 hertz using an exponential ramp so that the
filter *sounds* like it's smoothly moving through the frequencies at a
constant rate.  That's how human perception works.

But (1) requires a non-zero starting value.  This is quite simply the way
the math works for this shape.  If the value is zero, then the exponential
increase never has a chance to "take-off" and remains at zero, since any
value times zero still equals zero.

Chris
Received on Monday, 12 December 2011 01:59:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 12 December 2011 01:59:27 GMT