W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: Races - how bad?

From: Jer Noble <jer.noble@apple.com>
Date: Wed, 31 Jul 2013 16:52:09 -0700
Cc: Joseph Berkovitz <joe@noteflight.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
Message-id: <45E8ADFE-B622-41FC-862D-E32624A83C7A@apple.com>
To: Robert O'Callahan <robert@ocallahan.org>

On Jul 31, 2013, at 4:42 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> Excellent, thanks.
> 
> "An AudioBuffer is immutable if it is associated with a live AudioNode." should be clarified for the case where the live AudioNode is an AudioBufferSourceNode.

Is this not sufficient?:  "An AudioBufferSourceNode's live state is set immediately after its start() method is called, and its live state is cleared immediately after an ended event is dispatched to it.”

> (One problem is that the spec doesn't currently say what happens if the 'buffer' attribute is modified while the AudioBufferSourceNode is playing.) Can you make this precise?

Sure.  It should be sufficient to say something like “Setting the `buffer` attribute of a live AudioBufferSourceNode has no effect on the output of the node."

> Another issue is that you talk about status changes "after the dispatch of an event". It sounds like you change the status before the execution of the event handler; is this correct? That should probably be clarified.


I current have proposed that the AudioBufferSourceNode stops being a *live* node immediately after dispatching the `ended` event.  This is somewhat arbitrary, and could be changed to “immediately before dispatch”, which would no longer require that clarification.

However, I’ll add that clarification to the AudioProcessingEvent section.

-Jer



Received on Wednesday, 31 July 2013 23:52:36 UTC

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