Re: Questions about AudioParam

On Mon, Dec 10, 2012 at 2:31 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Oct 25, 2012 at 12:26 PM, Chris Rogers <crogers@google.com> wrote:
>
>> WebKit hasn't yet implemented this attribute, but I'm thinking that each
>> AudioParam will keep track of the latest .computedValue which is computed
>> every single render quantum in the audio thread.  Then the main JS thread
>> simply can read the latest value of this attribute.  WebKit *is* basically
>> computing this value every render quantum, but doesn't store it away to be
>> read by the attribute...
>
>
> I don't think it's a good idea to expose this kind of asynchronously
> varying data to Javascript.
>
> The basic issue is that since there's no way to synchronize the use of
> computedValue with any other operation, whatever value script reads from
> computedValue could be "wrong" as soon as it has read the value. (There
> could be an arbitrary delay between reading the value and returning it to
> the script.) That makes it almost impossible to use in a reliable way.
>
> I'm not sure what the intended use-cases are for computedValue, so it's
> hard to illustrate how this would cause problems in real applications. But
> for example, suppose an author tried to use computedValue to plot the
> values of several AudioParams against AudioContext.currentTime, using code
> like this:
> var x = context.currentTime;
> for (var i = 0; i < count; ++i) {
>   plot(x, audioParam[i].computedValue);
> }
> This obvious-looking code doesn't actually work reliably, since the values
> obtained by computedValue may not correspond to the values those params had
> at currentTime. In fact, if computedValue changes asynchronously there is
> no way to implement this example reliably.
>
> Assuming there are good use-cases for computedValue (what are they?), I
> propose that AudioContext.currentTime and computedValue reflect a
> consistent snapshot of the graph state. This snapshot would only be allowed
> to change during HTML5 stable states, when we know no script is running.
>
> Rob


Hi Robert, we don't necessarily have to expose this attribute to
JavaScript.  I mainly wanted a places in the specification where the
"computedValue" as used by the underlying audio DSP could be defined.  I
*do* think there are some interesting uses if we exposed this attribute,
especially for plotting its current value.

I appreciate your concern about the asynchronous and changing quality of
this value, and your point is well taken.  But this type of asynchronicity
has generally been an accepted fact of life in real-world desktop audio
applications when visualizing real-time audio data.  Graphical display of
characteristics of the audio signal commonly comes up when showing level
meters (usually indicated as a bar going from green to yellow to red), and
realtime frequency analysis, phase displays, etc.  In these cases the
UI/graphics are rendered in a different thread than the audio, so the
"sampling" of values from the audio thread is always jittering against the
audio rendering.  I have never seen any desktop audio applications go to
great lengths, for example, to ensure that the level meters of different
channels of a mixing board were all sampled from the same "audio render
quantum".  It's just not considered that much of an issue.

Chris