Re: New proposal for fixing race conditions

On Sat, Jul 27, 2013 at 7:29 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> On Fri, Jul 26, 2013 at 7:23 PM, Chris Wilson <cwilso@google.com> wrote:
>
>> Hmm.  Well, the channels being handled as an array of Float32Arrays would
>> be less structurally obvious.  Since the it is resampled to the
>> AudioContext rate anyway, the meta data is less interesting - although I'd
>> ideally like our decoding to have more metadata expressing the internals,
>> rather than less (e.g. original sample rate, any tempo tags, etc.).
>>
>
> Let's keep our use cases in check here. decodeAudioData is completely
> unsuitable for any scenario where you'd do anything with the  metadata.
>

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


> In all of the scenarios I can think of where you'd want to use the
> metadata you'd also want a completely more low-level construct, e.g. a
> streaming decoder. decodeAudioData is designed for one-shot samples,
> convolution kernels and oscillator waveforms, but then again for these use
> cases, it's a too low-level construct (because you have to do the XHR
> manually).
>

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


> On another note, I'd like to point out that the discussion has advanced to
> the point where we have provided suggestions that for most cases rival and
> potentially outperform in some situations, both in terms of CPU and memory
> usage, the current designs without imposing race conditions, but you still
> continue to take the stance that we should just define extensions to the
> other parts of the web platform just to allow racy things in our API?
>

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.


> IMO a lot of the proposals would improve the usability of the API as well,
> for example Marcus' suggestion to use arrays of Float32Arrays directly for
> the AudioProcessingEvent.
>

I hadn't replied one way or another on that particular proposal, because
I'm far more worried about AudioBuffers and BufferSourceNodes than I am
about AudioProcessingEvents.  I'm not sure I would object - strenuously or
otherwise - to that particular change, because I think the "intuitive
memory access lifetime" for the data associated with an
AudioProcessingEvent is, to me, pretty obvious.  At the same time, I
haven't thought through exactly what it buys you, and whether that's worth
the change.


> I can understand if your argument is backwards compatibility, but that's
> not the argument you seem to be making.
>

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.

-Chris

>