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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 May 2012 09:16:45 GMT