Re: memory footprint of AudioBuffer data copies

Since I was also talking about mutexes (my email crossed with kg's) I appreciate the clarification.

I think the following key clause in your proposal could be refined to more carefully identify what "in use" means:

	• An NO_MODIFICATION_ALLOWED_ERR exception must be thrown if the AudioBufferChannel is currently is use by a live AudioNode.

I missed the import of this statement at first. Now I see that set() confers a sort of temporary immutability on the AudioBuffer. This is a very significant aspect of your proposal (it originally contained the blanket statement "AudioBuffers are immutable", which this behavior descends from as I see it).

…j

On Jul 30, 2013, at 1:15 PM, Jer Noble <jer.noble@apple.com> wrote:

> 
> On Jul 30, 2013, at 10:04 AM, K. Gadd <kg@luminance.org> wrote:
> 
>> set() isn't automatically a race because you can have it acquire a mutex that the mixer holds when it's using the buffer as an input or output for mixing. Having a mutex acquired every time you set an element of a typed array does not seem like something VM implementers would have been excited to implement. The fact that timing is important is separate from the fact that unsynchronized access to a buffer from multiple threads is risky.
> 
> A mutex would be overkill here.  Both the start and end points occur on the main thread: after calling (e.g.) AudioBufferSourceNode.start(), further modifications to AudioBuffer would throw.  They would continue to throw until the ‘ended’ event fires.  Doing it this way (rather than acquiring a mutex when the audio thread begins accessing the memory) means the behavior is deterministic and specifiable.
> 
> -Jer

Received on Tuesday, 30 July 2013 17:22:50 UTC