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

Re: memory footprint of AudioBuffer data copies

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Tue, 30 Jul 2013 21:23:01 +0300
Message-ID: <CAJhzemV=EiWO7g7mbAz4HEuGECz7W0tWq-9ep=RU4Qps+RF+uQ@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
Cc: "K. Gadd" <kg@luminance.org>, Chris Wilson <cwilso@google.com>, Joseph Berkovitz <joe@noteflight.com>, WG WG <public-audio@w3.org>
On Tue, Jul 30, 2013 at 8: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.
>

This is the way I assumed it would work, and I think it's a very good
approach.

Cheers,
Jussi
Received on Tuesday, 30 July 2013 18:23:31 UTC

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