From the minutes of the audio wg teleconf on April 2nd: 
« The discussion on making it possible for the javascriptnodes to create audioparams for themselves reached some early consensus on making it a "nice to have", perhaps something to include in a future version of the web audio spec. Al will be gathering more input on this. (See ACTION-43).»

Closed per resolution at the 2012-05-02 audio WG teleconference. We will keep this in a "backlog" of potential features for a next version of the spec.

Comment from Marcus Geelnard, 4 Jun 2012, 08:07:19
«
First of all, sorry for being late with input to this. I hope I did the right thing here by re-opening the issue (?).

Adding to the previous discussions, I strongly feel that this is an important feature of the API.

Without the ability to have AudioParams on JavaScriptAudioNodes, it would not be possible to re-implement the native nodes for instance, e.g. for testing and reference implementations. It also makes it far more difficult to do drop-in replacements in an existing graph (e.g. if a developer wanted to make a custom filter node to replace a BiQuadFilterNode in an existing graph).

Generally speaking, it seems logical that the JavaScriptAudioNode is the most generic node with which you can implement "everything". Hence, support for AudioParam seems like a fundamental requirement.
»

We have seen several requests to bring this back since the April 2nd decision to keep it off the v1 scope. Can't seem to find any strong argument against it (major added complexity? Performance hit?). 

I would like to see pointers or arguments against bringing it back in scope, if there are any.

Regarding the suggested interface that returns a Float32Array... Returning a Float32Array would inevitably require GC. A better solution could be to fill out a Float32Array that is passed as an argument. I also think it would be a good idea to provide a method for returning a single value, for lessening the overhead for k-rate parameters.

E.g:

partial interface AudioProcessingEvent {
    void getParamValues(DOMString name, Float32Array values);
    float getParamValue(DOMString name);
}

(In reply to comment #4)
> Regarding the suggested interface that returns a Float32Array... Returning a
> Float32Array would inevitably require GC. A better solution could be to fill
> out a Float32Array that is passed as an argument. I also think it would be a
> good idea to provide a method for returning a single value, for lessening the
> overhead for k-rate parameters.
> 
> E.g:
> 
> partial interface AudioProcessingEvent {
>     void getParamValues(DOMString name, Float32Array values);
>     float getParamValue(DOMString name);
> }

Good idea!

I also just realized that Chris Rogers's suggestion for passing the param instead of the name won't play well with audio processing in workers.

(In reply to comment #5)
> I also just realized that Chris Rogers's suggestion for passing the param
> instead of the name won't play well with audio processing in workers.

Exactly.

Not quite sure what the best solution would be, but for now the "name" string should do (and you'd get an exception if you try to create two AudioParams with the same name).

If string/hash lookups are deemed too costly to do per-callback, we could introduce something similar to uniform/attribute locations in WebGL (i.e. integers).

I have an alternate proposal.

We probably don't really need the ability to directly instantiate a standalone AudioParam, we just need to allow a ScriptProcessorNode to own them, hence we could ask for them in the ScriptProcessorNode factory call:

    partial interface AudioContext {
        ScriptProcessorNode createScriptProcessor(unsigned long bufferSize,
            optional unsigned long numberOfInputChannels = 2,
            optional unsigned long numberOfOutputChannels = 2,
            optional unsigned long numberOfAudioParams = 0         // new
         );
    }

As far as I can see the AudioParam minValue, maxValue and units fields are all informational, so I've ignored them.

The ScriptProcessorNode does of course need to be expose these AudioParams so they can receive connections:

    partial interface ScriptProcessorNode {
        readonly attribute AudioParam param[];
    };

IMHO there's no need for direct name support - the developer can add a read-only named attribute that references the appropriate index into the param[] array if it's needed.

Rather than the "getParamValues()" value suggested above, I believe it should be possible to pre-calculate the animation curves and pass their values directly as part of the AudioProcessingEvent interface just as inputBuffer data is now:

    partial interface AudioProcessingEvent {
        readonly attribute AudioBuffer paramBuffer[];
    };

I believe the advantage of this approach is that it would simplify usage with WebWorkers - all of the required data is passed in one go.

(In reply to comment #7)
> I have an alternate proposal.
> 
> We probably don't really need the ability to directly instantiate a
> standalone AudioParam, we just need to allow a ScriptProcessorNode to own
> them, hence we could ask for them in the ScriptProcessorNode factory call:
> 
>     partial interface AudioContext {
>         ScriptProcessorNode createScriptProcessor(unsigned long bufferSize,
>             optional unsigned long numberOfInputChannels = 2,
>             optional unsigned long numberOfOutputChannels = 2,
>             optional unsigned long numberOfAudioParams = 0         // new
>          );
>     }
> 
> As far as I can see the AudioParam minValue, maxValue and units fields are
> all informational, so I've ignored them.
> 
> The ScriptProcessorNode does of course need to be expose these AudioParams
> so they can receive connections:
> 
>     partial interface ScriptProcessorNode {
>         readonly attribute AudioParam param[];
>     };
> 
> IMHO there's no need for direct name support - the developer can add a
> read-only named attribute that references the appropriate index into the
> param[] array if it's needed.

I like the idea of having anonymous AudioParams, it does indeed simplify things.

> Rather than the "getParamValues()" value suggested above, I believe it
> should be possible to pre-calculate the animation curves and pass their
> values directly as part of the AudioProcessingEvent interface just as
> inputBuffer data is now:
> 
>     partial interface AudioProcessingEvent {
>         readonly attribute AudioBuffer paramBuffer[];
>     };
> 
> I believe the advantage of this approach is that it would simplify usage
> with WebWorkers - all of the required data is passed in one go.

I'm not sure what you're after with this part. 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);
}

(In reply to comment #8)

> I like the idea of having anonymous AudioParams, it does indeed simplify
> things.

Great :)
 
> I'm not sure what you're after with this part. 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);
> }

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.

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.

(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.

Web Audio API issues have been migrated to Github. 
See https://github.com/WebAudio/web-audio-api/issues

Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.