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

Re: Proposal for fixing race conditions

From: Marcus Geelnard <mage@opera.com>
Date: Wed, 17 Jul 2013 23:43:14 +0200
Message-ID: <CAL8YEv6xn5Sp22cK49_t0hsybzkBywQOi0Jq=-21kn26n_4hSg@mail.gmail.com>
To: WG <public-audio@w3.org>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, Jer Noble <jer.noble@apple.com>, "robert@ocallahan.org" <robert@ocallahan.org>, "K. Gadd" <kg@luminance.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
On Wed, Jul 17, 2013 at 11:34 PM, Chris Rogers <crogers@google.com> wrote:

> On Wed, Jul 17, 2013 at 2:28 PM, Marcus Geelnard <mage@opera.com> wrote:
>> Just a few comments:
>> 0) First, let me re-iterate that I think that it's unacceptable for us to
>> move forward with a specification that allows for "shared mutable state
>> without locks" (as Jens Nockert so concisely put it). I really think that
>> we have to (and should be able to) find a solution to this.
>> 1) memcpy is really, really fast on any modern CPU architecture (you'll
>> find it's *the* most optimized routine, both in software and in hardware).
>> Having hand optimized graphics rasterization loops in assembler for ARM
>> I've learned that it's impossible to get even close to its speed even when
>> only doing trivial stuff, such as adding a constant value to a buffer or so.
> Marcus, this isn't so much an issue of how fast memcpy() is, although that
> could be a concern too.  It's about the overhead of the additional memory
> footprint (caused by the extra mallocs).
Even so, I'm not convinced that it's a real-world problem.

In most cases, I think that an application will simply upload audio data to
an AudioBuffer, and be done with it (i.e. the source data is GC:ed),
meaning no extra memory usage (except during a brief period during the copy

In some cases you would like to keep a JS side copy around (e.g. for an
audio editor), but then I think we're talking about an application that
would require quite much memory to begin with, and a factor 2x in RAM
consumption is not uncommon in content editing software (i.e, I don't
really see the problem).

Received on Wednesday, 17 July 2013 21:43:41 UTC

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