Re: memory footprint of AudioBuffer data copies

On Tue, 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.
>

That's what I've been saying; the memory access is the "issue" - not the
possibility of a race hazard, per se.


> However, you're correct that partially filling a buffer makes it possible
> for uninitialized/old audio to be played back. This has been a problem with
> almost every audio implementation I've ever interacted with, so maybe it's
> not worth trying to solve it in the browser context where user JS can get
> delayed by hundreds of milliseconds.
>

The other part of what I've been saying is that I don't consider this a
"problem" - the alternative is a strict isolation between the audio
thread's memory and the main memory, which from a developer's perspective
gets in my way more often than not.