Re: [Agenda] W3C Audio WG Teleconference, 30th May 2012

On Wed, 30 May 2012 15:42:13 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> On Thu, May 31, 2012 at 1:01 AM, olivier Thereaux <
> olivier.thereaux@bbc.co.uk> wrote:
>
>> * ISSUE-28: Script interaction (setting and reading) of most state is
>> under defined
>> http://www.w3.org/2011/audio/track/issues/28
>> Current Status: RAISED
>> Chris shared some of his thinking in the issue comments
>>
>
> Chris wrote:
>
>> Observing: the states MAY change during script execution. We believe we
>> have good automated test methods for testing things such as  
>> .playbackState,
>> and already test them today.
>>
>
> It's generally simpler for Web authors if states don't change during  
> script
> execution (except for changes explicitly made by the script), in  
> particular
> if scripts always see a consistent snapshot of the state of the graph.
> That's what MSP does. If we're not going to do this, I think we need a
> strong argument for not doing it, we'll need a careful description of  
> which
> states can change asynchronously and how, and we'll need to make sure  
> that
> scripts can actually safely read and do something with that state (which  
> is
> often not the case for state that can change asynchronously).
>
> Modifying: I believe it's critical to have modifications to the graph  
> state
>> happen immediately due to the real-time nature of audio (think real-time
>> synthesis where we have a MIDI API, playing notes in real-time). We  
>> need to
>> respond to the "command" noteOn() (or start() given a better naming)  
>> right
>> away as soon as we know for sure that this is what we want to happen.  
>> Any
>> delays caused by waiting for the script thread to finish, gc, etc. will
>> adversely affect this model and would be highly undesirable.
>>
>
> I think that deferring changes to happen atomically at the next stable
> state (in HTML5 terms) makes sense. That's what MSP does. That makes it
> very simple for Web authors to avoid glitches due to unintended
> intermediate states, without needing to introduce new atomicity  
> constructs
> and educate authors to use them correctly. I don't think Chris'  
> objections
> apply. Authors cannot and should not rely on their API calls happening at
> particular moments in real time. A GC or other pause happening after
> noteOn() and before the next stable state could just as easily have
> happened before the noteOn(). As a matter of general Web application
> design, scripts should not run long between stable states since that
> adversely affects almost everything in the page (including rendering  
> etc),
> so any delays introduced by deferring to the next stable state should be
> very short.
>
> If deferring changes to happen atomically at the next stable state is  
> still
> considered harmful, I'd like to see more detailed examples of scripts  
> that
> would be adversely affected.

We strongly agree with Robert. We have negative experiences with race  
conditions in the HTMLMediaElement API and do not want to implement  
something that we know will cause subtle and hard-to-reproduce bugs. The  
specification will require a lot more detail if state changes are  
reflected immediately, e.g. as in the ConvolverNode example we've given.

We suggest defining state modification (both by scripts and the audio  
graph) in terms of tasks [1] such that e.g. modifying the ConvolverNode  
properties will queue a task to atomically apply the changes to the  
underlying audio graph.

[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-source

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Friday, 1 June 2012 13:14:08 UTC