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:18:08 -0700
Message-ID: <CAJK2wqXSP4FuDmgGtTd2h=NB6iAm5CepEArE2ENp_5+qGZ5yGQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Chris Rogers <crogers@google.com>, Marcus Geelnard <mage@opera.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, Jer Noble <jer.noble@apple.com>, Russell McClellan <russell@motu.com>, WG <public-audio@w3.org>
On Tue, Jul 23, 2013 at 3:26 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, Jul 24, 2013 at 9:18 AM, Chris Rogers <crogers@google.com> wrote:
>
>> On Tue, Jul 23, 2013 at 1:10 PM, Chris Wilson <cwilso@google.com> wrote:
>>
>>> OK.  I want to load an audio file, perform some custom analysis on it
>>> (e.g. determine average volume), perform some custom (offline) processing
>>> on the buffer based on that analysis (e.g. soft limiting), and then play
>>> the resulting buffer.
>>>
>>
> My original proposal (as implemented in Gecko) makes no extra copies here.
> The play operation neuters the JS array(s) and migrates the data to the
> audio thread.
>

I must be looking at the wrong proposal. (
http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0644.html)
implies the load (which would create an AudioBuffer) creates one instance
of the data, and the "acquire contents" (in order to perform analysis and
processing) would create a copy.
Received on Friday, 26 July 2013 16:18:35 UTC

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