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

Re: Preparing the vote on the data race issue

From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date: Tue, 30 Jul 2013 17:24:21 -0400
Message-ID: <CANTur_6AFfrAfbpwU4hcWZPnTrfB+XuC=bEgUx8WCJ7KTScrng@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
Cc: Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, Joseph Berkovitz <joe@noteflight.com>, WG <public-audio@w3.org>
On Mon, Jul 29, 2013 at 3:55 PM, Jer Noble <jer.noble@apple.com> wrote:

> On Jul 29, 2013, at 8:44 AM, Jer Noble <jer.noble@apple.com> wrote:
> >
> > On Jul 29, 2013, at 3:35 AM, Olivier Thereaux <
> Olivier.Thereaux@bbc.co.uk> wrote:
> >
> >> My understanding was that Jer's proposal (for lack of a better term - I
> know that Jer has said it was not his preferred solution, only a proposed
> compromise) was the first one listed in the gist I shared, but I might be
> wrong.
> >
> > Sorry, I've been on vacation for the last week.  I'll clean up that Gist
> with the feedback received so far, and narrow it to a single, explicit
> proposal.
> >
> I’ve updated the gist <https://gist.github.com/jernoble/6034137> to
> remove all references to “alternatives” and added a section about memory
> and performance considerations.

Thanks for doing this, Jer!

A few issues about your proposal:

* In the AudioBuffer constructor, I believe you want to accept a sequence,
not an array.
* I think you want to convert AudioBuffer.channels to be a sequence as well.
* Should AudioProcessingEvent.outputBuffer be nullable?  I don't think that
it makes sense to require the implementation to allocate an object (even
lazily) if it's going to be overwritten in the typical use case.
* Float32Array is not a regular Web IDL interface <
http://www.khronos.org/registry/typedarray/specs/latest/#7> so you cannot
extend it with the partial interface syntax (AFAIK).

Received on Tuesday, 30 July 2013 21:25:29 UTC

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