Re: [web-audio-api] (audioparam): AudioParam constructor (#134)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388#9) by Marcus Geelnard (Opera) on W3C Bugzilla. Tue, 04 Dec 2012 09:28:07 GMT

(In reply to [comment #9](#issuecomment-24244466))
> (In reply to [comment #8](#issuecomment-24244457))
> > 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.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/134#issuecomment-24244474