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

Re: Proposal for fixing race conditions

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 17 Jul 2013 14:42:51 +1200
Message-ID: <CAOp6jLYFnidm2HT-_wG6vEFKj2BOgKk9LJHfAW7TnooH-7cheQ@mail.gmail.com>
To: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
Cc: "K. Gadd" <kg@luminance.org>, Jer Noble <jer.noble@apple.com>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, WG <public-audio@w3.org>
On Wed, Jul 17, 2013 at 2:24 PM, Srikumar Karaikudi Subramanian <
srikumarks@gmail.com> wrote:

> Your hypothetical test case merely demonstrates the difference; my point
> is that it is silly to optimize for imaginary edge cases at the cost of
> real-world use cases where developers will get unexpected results due to
> leaving race conditions in this API. I should also note that it has come up
> in past discussions that we could always introduce new no-copy APIs that
> don't contain races, if the cost of memcpy is so severe.
>
>
> It is not inconceivable to make an audio editor which plays an audio file
> from a specific sample onwards by assigning the buffer to an
> AudioBufferSourceNode and using start(t,offset,duration) ... possibly
> followed by effects. Large files (even 5mins?) would be unusable with such
> an editor if a copy were involved and clients/devs will be forced to do
> crazy optimizations just to get it to work.
>

Are you suggesting the editor would play the audio data while
simultaneously allowing the user to edit it?

If so, that's a good example of how race conditions are likely to lead to
bizarre and unpredictable behavior.

If not, then if my proposal is adopted, a browser could handle this case
efficiently. When a stop() call means the audio thread no longer needs
access to a buffer, the memory can be returned to the AudioBufferSourceNode
so that the next call to getChannelData() can use that memory again instead
of copying it.

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 Wednesday, 17 July 2013 02:43:19 UTC

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