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

[Bug 17327] (ScriptStateInteraction): Script interaction (setting and reading) of most state is underdefined

From: <bugzilla@jessica.w3.org>
Date: Thu, 07 Jun 2012 15:55:44 +0000
To: public-audio@w3.org
Message-Id: <E1Scf3o-0001Yr-UQ@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17327

Olivier Thereaux <olivier.thereaux@bbc.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |olivier.thereaux@bbc.co.uk
         AssignedTo|dave.null@w3.org            |crogers@google.com

--- Comment #1 from Olivier Thereaux <olivier.thereaux@bbc.co.uk> 2012-06-07 15:55:44 UTC ---
Comment from Chris Rogers, 18 May 2012


I'll need to add more detail into the spec. Here's my thinking:

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.

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.

That said, there could be some advanced uses cases (not yet required or
demanded by any Web Audio developers) where more complex and atomic changes to
the graph will be necessary. For this, I propose something along the lines of:

context.beginAtomicChanges();
...
context.endAtomicChanges();

Once again, I believe I can demonstrate that these atomic changes will be
rarely needed so won't overly complicate the JS code for developers in nearly
all cases.
But we should support them for certain advanced cases, and will need to work
out exactly the details...

Regarding your example of ConvolverNode -- I don't believe this specific
example will be a problem, but I can understand your confusion because I
haven't fully explained how these work. Give me some time...

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 7 June 2012 15:55:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 June 2012 15:55:53 GMT