Re: Races - how bad?

1. In the "Memory and Performance Considerations" section, the text -

> Generating audio directly into an AudioBuffer using the new set() method will still result in 0-additional allocations or copies.


is likely dated and ought to be removed? AudioBuffer doesn't have a set() method and the set() method on AudioBufferChannel does require a copy as per its description.

2. It may be clearer to make it explicit that an AudioBuffer can be "associated with" multiple AudioNodes, some of which may be live and some not and that the AudioBuffer is to be immutable as long as at least one of these AudioNodes is live. The current "associated with" language reads close to one-to-one association.

3. There is some residual nondeterminism with the ConvolverNode's liveness being tied to its connect()/disconnect() calls. If a convolver node is part of a voice's effect chain, it can be released without an explicit disconnect() call and at a time that is not predictable due to reverb tails and "dynamic lifetime". Not sure if this needs fixing or can be fixed, but just pointing it out.

-Kumar
http://sriku.org

On 1 Aug, 2013, at 4:59 AM, Jer Noble <jer.noble@apple.com> wrote:

> I’ve updated the proposal <https://gist.github.com/jernoble/6034137> to enumerate when an AudioNode is *live*, and these states are deterministic and predictable.
> 
> -Jer

Received on Thursday, 1 August 2013 01:51:36 UTC