Re: New proposal for fixing race conditions

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".

-C