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

Re: New proposal for fixing race conditions

From: Chris Wilson <cwilso@google.com>
Date: Fri, 26 Jul 2013 09:14:18 -0700
Message-ID: <CAJK2wqW4db7sH9Yw-+z_WWDMCk6PW9d_A1YRuyrJYQR16MJ-WA@mail.gmail.com>
To: Marcus Geelnard <mage@opera.com>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>, Jer Noble <jer.noble@apple.com>, Russell McClellan <russell@motu.com>, WG <public-audio@w3.org>
First, I apologize for dropping this discussion for a couple of days - busy
with other things, then got sick and dropped everything.

On Tue, Jul 23, 2013 at 2:52 PM, Marcus Geelnard <mage@opera.com> wrote:

> In other words 2x memcpy of the buffer would amount to < 0.4% of the total
> processing time, and that's for a very trivial operation (for more complex
> processing, the memcpy would be even less noticeable).

As noted elsewhere - the performance is a minor concern compared to memory
footprint and hoops-developers-have-to-jump-through.

> True, this *might* be a problem, but if you're creating an app that even
> comes close to using 50% of your available memory for audio buffers alone,
> I'd say that you're in deep trouble anyway (I think it will be very hard to
> make such an app work cross-platform).

I could easily write an app that works fine on a desktop, but is
memory-contrained in mobile devices.

In fact, here's another thought: With Jer's proposal an implementation is
> no longer forced to using flat Float32 arrays internally, meaning that it
> would be possible for an implementation to use various forms of compression
> techniques for the AudioBuffers. For instance, on a low memory device you
> could use 16-bit integers instead of 32-bit floats for the audio buffers,
> which would *save* memory compared to the current design (which prevents
> these kinds of memory optimizations).

THAT sounds like something that would create lots of cross-implementation
behavior differences, and should be avoided.  Or may that's just me.

> Oh, and with regards to the "it's usually not a problem" analogy - point
> taken. However, from my point of view we're talking about a few corner
> cases where we'll see a slight (temporary) increase in memory consumption
> (in the normal use case, there'll be no difference) vs breaking the way the
> Web works (as has been explained in various ways by different people on
> this list).

Sigh.  I should own up, I have an allergic reaction any time someone uses
the phrase "breaking the way the Web works".

I don't think it's a slight, nor necessarily temporary (you're relying on
good developer hygiene) increase.

> I guess this is what is dividing the group into two camps right now.
> Personally, I'd much rather go with the potential memory increase than
> breaking typed arrays (i.e. I'm in the "let's keep the Web webby" camp).

Please be more concrete in the low-level principles being violated, because
of course no one would vote against "keeping the Web webby".  But I could
also say protecting developers from having to deal with low-level memory
issues is what makes the Web "webby".

Received on Friday, 26 July 2013 16:14:45 UTC

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