AudioParamDescriptor has member constraints that are redundant

[bzbarsky]

https://webaudio.github.io/web-audio-api/#dictionary-audioparamdescriptor-members describes various constraints on its members. For example, for defaultValue it says:

If this value is out of the range of float data type or the range defined by minValue and maxValue, a NotSupportedError exception MUST be thrown

That first constraint is redundant with the fact that it's declared as float in the IDL: the algorithm at https://heycam.github.io/webidl/#es-to-float will already throw on out-of-range values, before any of this spec's logic happens. So it can just be removed.

The second constraint is redundant with https://webaudio.github.io/web-audio-api/#dom-audioworkletglobalscope-registerprocessor step 9 (though I took a look at the Blink code and I don't see it being enforced either in their version of step 7 or in step 9; I might have missed it, of course).

Similar for the other constraints here, including the one on "name"; that's enforced by https://webaudio.github.io/web-audio-api/#dom-audioworkletglobalscope-registerprocessor step 9 too.

@padenot

[rtoy]

Teleconf: Yes, these need to be fixed.

[rtoy]

So basically:

• remove the stuff about being out of range for a float.
• constraint on defaultValue being between min and max and throwing a NotSupportedError is inconsistent with step 9 of the register processor algorithm, and also redundant.
• constraint on name throwing an error is also described in step 9.

For the latter two, just remove the error conditions from AudioParamDescriptor?

I kind of like that here, but two places saying the same thing is bad. If we remove these, we should link to the appropriate steps in the algorithm for the constraints. Otherwise, most devs will probably never find the constraints without lots of digging.

[padenot]

For the latter two, just remove the error conditions from AudioParamDescriptor?

I think so yes.

[rtoy]

On the other hand, should we keep the constraints in AudioParamDescriptor dictionary (which is where the user sets the various attributes) and remove the checks from the registerProcessor algorithm?

[bzbarsky]

The place where the checks actually end up needing to happen is in the registerProcessor algorithm: dictionaries do not have behavior associated with them in the IDL spec.

[rtoy]

Ok. I'll update them then. Thanks.