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

Re: New proposal for fixing race conditions

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Fri, 19 Jul 2013 10:33:52 +0300
Message-ID: <CAJhzemVhC0HcmKGvNJR0UgeWhSKwrEq9Zeb2AMHztnYM00rFQQ@mail.gmail.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Cc: Jer Noble <jer.noble@apple.com>, "Robert O'Callahan" <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>
I'm OK with this solution although I fail to really the see the use case of
post-creation modifying AudioBuffers. I'd also suggest that instead of a
slice() there would be a function to copy the data to an existing array,
not sure what would be the logical name of that method (it should actually
be an overload of Float32Array#set() since it's inversion of control, and
it's hard to name out-of-place methods, but I doubt we want to touch
Float32Array), but the signature would be something like:

void copyTo (Float32Array target, optional unsigned long offset);

So that would change forced memset + malloc to just memset and leave the
malloc up to the developer.


On Fri, Jul 19, 2013 at 5:11 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> I also think the combination is a good idea.
> --
> Ehsan
> <http://ehsanakhgari.org/>
> On Thu, Jul 18, 2013 at 8:09 PM, Jer Noble <jer.noble@apple.com> wrote:
>> On Jul 18, 2013, at 4:54 PM, Robert O'Callahan <robert@ocallahan.org>
>> wrote:
>>  Both of those proposals look pretty good to me.
>> I would also support a combination of the proposals that lets
>> AudioBuffers be mutable, but adds "Constructor(Float32Array[] arrays, float
>> sampleRate)" and makes outputBuffer non-readonly.
>> I thought that might be popular.  :)
>> I’m updating the proposal here: <https://gist.github.com/jernoble/6034137>,
>> and I’ll incorporate suggestions (including this one).
>> -Jer
Received on Friday, 19 July 2013 07:34:20 UTC

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