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.

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.4.0 : Friday, 17 January 2020 19:03:23 UTC