Re: New proposal for fixing race conditions

On Mon, Jul 29, 2013 at 7:31 PM, Chris Wilson <cwilso@google.com> wrote:

> Actually, the scenario I'd wanted this for is my DJ demo, where I'd like
> to pick up the tempo metadata that's frequently stored, so no, I'd have to
> argue it's not "completely unsuitable".
>

To be clear, I think that anything with a tempo doesn't belong in an
AudioBuffer. Items that have a tempo are often long enough to quite quickly
exceed the memory usage quota (IIRC a presentation I watched talked about a
10MB quota, and that was about console games, e.g. PS2) reserved for audio
on low-end devices. If your DJ demo is desktop only, sure, go right ahead.
And I might be overly serious about this, but since we're talking
performance.


> I think doing XHR manually is flexibility, rather than a drawback.  I
> might want to be pulling that data from local storage.  But then, I'm not
> even remotely try to argue that decodeAudioData is the only API that should
> ever load and decode audio buffers, so I'm not sure why you're trying to
> keep my use cases "in check" - all I'd said was that if the output of
> decodeAudioData was an array of ArrayBuffers, you lost a place to hang
> metadata and channel layout, which I believe is true.  (I don't agree, BTW,
> that decodeAudioData is usable only for buffers of a few seconds in length,
> but I don't think this is particularly germane.)
>

Flexibility is fine, but we have blob URIs for that use case (getting stuff
from localStorage). IMHO worst case scenario if we need to extend the API
is that we'll have to attach the metadata into the array returned (eww),
but I'd much prefer we made a proper decoder API instead of adding use
cases to this one.

I'm sorry I'm obviously frustrating you.  I haven't seen suggestions that
> for most cases rival and potentially outperform (?) the current API in
> terms of CPU and memory usage, and some of them make the API much less easy
> to use, in my opinion.  You're translating my concern that the API be
> efficient and intuitive in common cases to "screw you, I want racy things
> in our API".  As I'm sure you can understand, I'm not too pleased to be
> translated in that way.
>

No no, I'm not frustrated, just confused, so I asked for clarification to
see if we are on the same page. Sorry if frustration was the message I
conveyed. Well my suggestion to skip change the input of decodeAudioData
will most certainly outperform the current design and be easier to use for
the common cases. Jer's proposal (if it would, as I suggested, have a
constructor that neuters given array buffers) won't perform any worse than
the current situation except in corner cases and indeed will outperform the
current API if you already have PCM data as a Float32Array and want to
convert it to an AudioBuffer.


> To me (Chris may feel differently), backwards compatibility is
> considerably less of a concern than building an efficient, intuitive and
> well-designed API.  Obviously, that means different things to different
> people.
>

I'm extremely glad to hear that, although not surprised!

Cheers,
Jussi