[Bug 17388] (audioparam): AudioParam constructor

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388

--- Comment #10 from Marcus Geelnard (Opera) <mage@opera.com> ---
(In reply to comment #9)
> (In reply to comment #8)
> > Your suggestion has no way of
> > differentiating between k-rate and a-rate parameter inputs, which has
> > implications on performance. I think that we should just change the previous
> > proposal a bit to accommodate:
> > 
> > partial interface AudioProcessingEvent {
> >     void getParamValues(uint index, Float32Array values);
> >     float getParamValue(uint index);
> > }

I agree.

> AIUI, whether an AudioParam is a-rate or k-rate depends on the specification
> of each type of AudioNode.  It's actually not clear to me that k-rate
> AudioParams make sense in the context of a ScriptProcessorNode.

Well, there are certainly use cases where you'd want to use k-rate params. Just
have a look at the existing nodes in the spec, and imagine that you want to
re-implement a variant of one of them as a script processor node.

I tend to think of k-rate parameters as constants or slowly varying parameters
that you want to control in the same manner as any other (e.g. a-rate)
parameter, e.g. using knobs in a UI etc.

It's true that you can achieve k-rate behavior in your script by simply picking
the first sample from an a-rate parameter array, which could be a performance
win for you algorithm, but on the other hand the audio engine would still have
to generate all the a-rate samples for you, which is a potential performance
loss.

> I'm not intimately familiar with the internals of any of the WebAudio
> implementations, but it sounds like your second function prototype wouldn't
> fit with the requirement that k-rate samples are taken on a 128 sample block
> boundary, given that a ScriptProcessorNode could easily be processing a
> block longer than that.

True. Either the spec has to be clear on this (i.e. specifying that
getParamValue() samples at the beginning of the event buffer), or we need to
add another parameter, e.g. like this:

float getParamValue(uint index, double time);

I think that the first option would suffice, though. If you need more fine
grained sampling, you're probably looking for an a-rate solution anyway, or you
can use getParamValues() and decide the processing batch size yourself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 4 December 2012 09:28:13 UTC