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

Re: [web-audio-api] Web Audio API can't be implemented in JS (#242)

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 20 Sep 2013 19:17:51 +1200
Message-ID: <CAOp6jLYzht3u5Ofmdm-7Pi1nq4_WHMFi=kjO=2WgZ4EqzUzuoQ@mail.gmail.com>
To: "WebAudio/web-audio-api" <reply+i-19797080-80c49b9e44e529d493d9f3f6fdc9892cc84b3c88-3491421@reply.github.>
Cc: "WebAudio/web-audio-api" <web-audio-api@noreply.github.com>, W3C Audio Working Group Notifications <public-audio@w3.org>
On Fri, Sep 20, 2013 at 7:09 PM, Jussi Kalliokoski <notifications@github.com
> wrote:

> What things?
> Gecko never has the main thread wait on the audio thread.
> How have you implemented getChannelData then? As a quick shot at it the
> only ways I can think of to do this:
>    - The audio data of AudioBuffers is stored on the main thread and
>    copied to the audio thread whenever AudioBufferSourceNode#buffer is
>    set. I suppose this would be the most viable option for JS, but terribly
>    inefficient.
>    - Shared memory? Probably not, since that would go against your
>    proposal. :)
>    - COW? This seems like the most likely option to me, but this can't be
>    done in JS.
basically what we do.

While we're in the arrays-neutered state, the buffer data is stored in an
ImmutableBufferSet which is readable by both the main thread and the audio
thread at any time. This is innocuous since, like it says on the label,
that data is immutable.

When we talk about shared memory being a problem, it's only a problem when
one thread can write to the memory while another thread reads it. Immutable
data in shared memory is all good.

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 Friday, 20 September 2013 07:18:19 UTC

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