W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

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

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 18 May 2012 11:16:16 +0200
To: public-audio@w3.org, "Audio Working Group Issue Tracker" <sysbot+tracker@w3.org>
Message-ID: <op.wehypengsr6mfa@kirk>
On Tue, 15 May 2012 15:18:35 +0200, Audio Working Group Issue Tracker  
<sysbot+tracker@w3.org> wrote:

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

Another example of where this is problematic is WaveShaperNode, where it's  
not defined what happens when curve is modified.

Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 18 May 2012 09:16:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:04 UTC