Intrinsic value of AudioParam after disconnection

[hoch]

var context = new AudioContext();
var osc = context.createOscillator();
var amp = context.createGain();
osc.frequency.value = 0.1;
osc.connect(amp.gain);
osc.start();

// and some time later...
osc.disconnect();

What is the value of amp.gain after the disconnection? What would be the right behavior?

This is something should be documented in the spec. @rtoy and I talked about this and we prefer to leave the intrinsic value alone. So we change nothing in the implementation, but it is actually better that way.

Falling back to the default value or resetting to the last value set by user will result clicks and clitches.

[hoch]

This is closely related to the issue #318.

[notthetup]

I should just try this out, but as long as the getter for .value returns the intrinsic value, I feel it should be alright to keep the value.

[hoch]

@notthetup Note that getting the value from the .value getter will not be sample accurate since it should go through the process hop. (audio thread to main JS thread) So it might not be useful for the scenario requires hight precision.

Exposing the intrinsic value shouldn't be too hard in terms of the implementation, I am not sure if it is really worth it.

[notthetup]

Ah! I meant to say after the oscillator has been disconnected, if the .value getter returns the the intrinsic value, then I feel that's good enough.

Because then it's easy to query the state of the amp gain and decide if it should be faded out etc.

[hoch]

@notthetup Ah, yes - I agree with that. Sniffing the intrinsic value is actually useful in this particular scenario.

[hoch]

Just to clarify, plugging in the node output to an AudioParam object means the addition of the AudioParam value and the incoming audio stream. So when the audio stream stops or disconnects, the result will instantly jump to the intrinsic value of AudioParam.

http://webaudio.github.io/web-audio-api/#widl-AudioNode-connect-void-AudioParam-destination-unsigned-long-output

An AudioParam will take the rendered audio data from any AudioNode output connected to it and convert it to mono by down-mixing if it is not already mono, then mix it together with other such outputs and finally will mix with the intrinsic parameter value (the value the AudioParam would normally have without any audio connections), including any timeline changes scheduled for the parameter.

The verb 'mix' is a bit vague, I think. It actually means the arithmetic addition in the implementation.

[padenot]

I think we should just change the text here.

[joeberkovitz]

Nothing to do here, since data from connected nodes does not affect the intrinsic value returned by the value getter. We still have the problem of deciding whether automation affects the getter result but that is another issue.