1504984 - Implement AudioParam automationRate

Status: NEW

(Core :: Web Audio, enhancement, P3)

Description

[Arnaud Bienner]

Follow up of bug 1504982.

TODO:
* update AudioParam.webidl to automationRate attribute
* update AudioParams implementation (maybe should be split in different bugs)

Comment 1

[Karl Tomlinson (:karlt)]

https://github.com/WebAudio/web-audio-api/pull/1521

One thing to consider here, if splitting this in two parts, is whether it would be helpful or unhelpful to ship an automationRate attribute with incomplete implementation.

Options are:

1) Don't ship AudioParam.automationRate until implementation is complete.

   Feature detection is clear with this option.

2) Ship a functional getter but throw from the setter.

   Provides some introspection.  Feature detection is available but not
   intuitive because this configuration was never specified, I assume.

3) Ship a getter and setter that appear to work, but the value actually
   has no effect on output.

   This avoids exceptions in code that expects automationRate to be present,
   but provides no nice feature detection.

   The lack of effect on output would be minor, assuming the setter can
   only downgrade.  Missing a downgrade opportunity would have an effect
   on performance.

I'm currently leaning towards option 1, given no known existing problems with web compat.  This could still be implemented in parts, but then it would need to be behind a preference.

Comment 2

[Arnaud Bienner]

What I meant by splitting was to have separate patches to ease reviews, and separate bugs to ease discussions about specific parts (I'm not sure how much work is required to implement the whole thing).
Option 1 also looks to me as the best option.
Do we want to make this bug block AudioWorklet implementation? I guess so, given that AudioWorklet will have custom AudioParams using automationRate, and this is probably the usecase where it will be the most useful.

Comment 3

[Karl Tomlinson (:karlt)]

This is not required to implement AudioWorklet, and so does not need to block AudioWorklet.

It is useful if the client would like to use different instances of the same kind of worklet node with different automation rates, but that doesn't seem to be top-priority scenario.

Comment 5

[Arnaud Bienner]

Oops, I commented on the wrong bug, sorry.