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

Re: New proposal for fixing race conditions

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 24 Jul 2013 10:26:48 +1200
Message-ID: <CAOp6jLYpqu0shTZFbxyz5z_+7Zi5o1ws1vmL=_OaoVM0_dx=5A@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: Chris Wilson <cwilso@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 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.

And I can add two more realistic use cases here:
>
> * at any stage analyze and display the resulting buffer as a waveform on
> the screen for an audio editor
>

If you do this while the data is playing, my proposal will copy the data.


> * generate AudioBuffer PCM data directly in JavaScript which then gets
> played back using an AudioBufferSourceNode
>

My proposal makes no extra copies here.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*
Received on Tuesday, 23 July 2013 22:27:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC