Re: memory footprint of AudioBuffer data copies

On Jul 30, 2013, at 11:38 AM, Chris Wilson <cwilso@google.com> wrote:

> Um.  I'm seriously confused now.  If you're saying you can set() into a range of a currently-playing buffer, then that seems to introduce precisely the same timing race opportunities that the current model has; how is this different?

First, I agree that we're never going to rid ourselves of some degree of unpredictability over exactly what the audio thread sees or doesn't see; all of the proposals on the table seem geared to imposing a degree of atomicity/coarse-graining on changes made on the main thread, but no more than that. What people appear to be most bothered by is the fact that *partial* operations in one thread have an effect in another. In the shared memory model. in particular, "partial" could mean "incomplete modification".

If one thinks the latter problem is a big deal, then Jer's proposal does seem to help (as does ROC's). And as I understand it, the call to set() (or any of the other calls) introduces the opportunity to acquire a mutex which can synchronize interleaved audio thread and main thread access.

At a minimum this would prevent the partial results of a set() call from ever being seen on the audio thread. But with more clever mutex management, it could block the audio thread until the main thread yields or performs one of some other set of Web Audio actions explicitly designated as giving up the mutex. 

I would think this latter question needs to be specced out in more detail. The question of mutex management appears to have been a big debating point with the Local Storage API and the outcome apparently wasn't very satisfactory.

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"