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

Re: TAG feedback on Web Audio

From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date: Thu, 8 Aug 2013 11:21:27 -0400
Message-ID: <CANTur_410Z8YzrK1gL_Ncufe2D7vq--fYUNsem1NaydqtN_hjQ@mail.gmail.com>
To: Joseph Berkovitz <joe@noteflight.com>
Cc: Marcus Geelnard <mage@opera.com>, Noah Mendelsohn <nrm@arcanedomain.com>, "Robert O'Callahan" <robert@ocallahan.org>, Jer Noble <jer.noble@apple.com>, "K. Gadd" <kg@luminance.org>, Srikumar Karaikudi Subramanian <srikumarks@gmail.com>, Chris Wilson <cwilso@google.com>, Alex Russell <slightlyoff@google.com>, Anne van Kesteren <annevk@annevk.nl>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, "public-audio@w3.org" <public-audio@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
On Thu, Aug 8, 2013 at 9:59 AM, Joseph Berkovitz <joe@noteflight.com> wrote:

> On Aug 8, 2013, at 6:16 AM, Marcus Geelnard <mage@opera.com> wrote:
> I strongly believe that the most critical part of the current API that
> could potentially block such future directions is the requirement that the
> audio data buffers must be shared between the audio engine and the JS
> engine. It might seem to be an optimal solution (performance wise) right
> now, but it literally kills many attempts to move audio processing off-CPU
> (e.g. try to imagine the limitations imposed on a hardware accelerated 3D
> graphics processor if it had to be able to observe data mutations made by
> the CPU in shared RAM).
> To be accurate, I don't think the proponents of retaining the current API
> approach have asked that sharing memory be a requirement -- only that it
> should be permitted, and is desirable under "safe" timing scenarios, but
> not to be relied upon in "risky" ones. It would, I think, be possible to
> implement something like ROC's proposal minus the neutering and still
> conform to the current API, while getting rid of potential shared-memory
> side effects.

No.  Our current implementation in Gecko violates the spec in that it
neuters the ArrayBuffers when their owner AudioBuffer is "in use", which is
not something required by the current spec.  The spec leaves the memory
access patterns issue completely unaddressed, but I believe the proponents
of the current API have defended the shared memory model at least for
AudioBufferSourceNode.buffer in the discussion here several times.  The
"leave things as they are" and "shared memory model" approaches are really
the same thing.

That said, an eagerly copying implementation where the contents of the
AudioBuffer are copied right when the buffer attribute is set is
technically not violating the current spec, but I believe that's mostly
because the shared memory model intended here is underspecified.  Once the
specification is clear on that (which is going to be a huge effort,
spec'ing data race conditions is extremely hard!) then it won't be possible
to implement Web Audio anywhere that shared memory is not available.

Received on Thursday, 8 August 2013 15:22:35 UTC

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