[web-audio-api] (ScriptStateInteraction): Script interaction (setting and reading) of most state is underdefined (#108)

> Originally reported on W3C Bugzilla [ISSUE-17327](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17327) Tue, 05 Jun 2012 11:19:28 GMT
> Reported by Philip Jägenstedt
> Assigned to 

Audio-ISSUE-28 (ScriptStateInteraction): Script interaction (setting and reading) of most state is underdefined [Web Audio API]

http://www.w3.org/2011/audio/track/issues/28

Raised by: Philip Jägenstedt
On product: Web Audio API

How scripts observe and modify the state of the audio graph has big consequences for both implementation complexity and ease of use for Web authors.

Observing:

Can long-running scripts busy-wait and monitor changes to AudioContext.currentTime, AudioBufferSourceNode.playbackState, Oscillator.playbackState and AudioParam.value? (HTMLMediaElement.currentTime is held stable during script execution.)

Modifying:

When modification are made to the graph, when do they take effect? Should conforming implementations work with long-running scripts that continuously modify some state, or should all modifications made be applied atomically after the script thread has finished.

Recommendations:

For observing, it's not clear what is the best solution. Showing scripts a stable state is probably simpler to specify, simpler to write a test suite for (since otherwise state may at any time be inconsistent, a big problem in testing HTMLMediaElement) but hard to implement as an after-thought.

For modifications, it seems wise to apply all changes as a single "transaction" after the script has finished running. Otherwise, intermediary states could cause audible glitches if GC is run for even a few milliseconds between the two setters. An example would be changing ConvolverNode.buffer and normalize. If the change to normalize takes effect some time after the change to buffer, one could hear a loud pop or gap of silence generated from the inconsistent combination of the new buffer and old normalize value.

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