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

Re: memory footprint of AudioBuffer data copies

From: Chris Wilson <cwilso@google.com>
Date: Tue, 30 Jul 2013 10:10:36 -0700
Message-ID: <CAJK2wqVkS_CFpRT6giZiuqPm5BG9whG8QR2D-S-2CNBacNSPtQ@mail.gmail.com>
To: kg@luminance.org
Cc: Jer Noble <jer.noble@apple.com>, Joseph Berkovitz <joe@noteflight.com>, WG WG <public-audio@w3.org>
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.
Received on Tuesday, 30 July 2013 17:11:05 UTC

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