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

Re: Races - how bad?

From: Joe Berkovitz <joe@noteflight.com>
Date: Wed, 31 Jul 2013 20:03:59 -0400
Message-Id: <4B6251AD-39DA-4EE3-A344-CB899D186C27@noteflight.com>
Cc: Robert O'Callahan <robert@ocallahan.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
To: Jer Noble <jer.noble@apple.com>
On Jul 31, 2013, at 7:52 PM, Jer Noble <jer.noble@apple.com> wrote:

> 
> 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.”

Thanks. This now appears to be deterministic. Previously I thought you meant that the live state commenced when the node started to play, but this clarifies that it commences when the node is requested to play in the future. So I think it removes the uncertainty. 

> 
>> 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.

Also sounds good. 
Received on Thursday, 1 August 2013 00:04:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC