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

Re: AudioBuffer channel read/write APIs

From: Jer Noble <jer.noble@apple.com>
Date: Thu, 12 Sep 2013 11:49:20 -0700
Cc: Robert O'Callahan <robert@ocallahan.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, Marcus Geelnard <mage@opera.com>, "public-audio@w3.org" <public-audio@w3.org>
Message-id: <754F56C5-88BD-4AC3-8CD7-4EADCB25ABC8@apple.com>
To: "K. Gadd" <kg@luminance.org>

On Sep 12, 2013, at 11:27 AM, K. Gadd <kg@luminance.org> wrote:

> So essentially I think I'm asking for the Web Audio version of a given API to be as expressive and symmetric as the C version would be, where reasonable. This seems like a good opportunity, since it's speccing a new API that basically just exposes two special variants of memcpy.
> 
> (That's also why I'm okay with a version that is just one buffer and an offset, since everything else can be expressed via a view, if you ignore the performance consequences)


FWIW, JSC has been doing a lot of work lately to ensure that the performance implications of creating a new TypedArrayView are as minimal as possible.

See:
https://lists.webkit.org/pipermail/webkit-dev/2013-August/025267.html
https://bugs.webkit.org/show_bug.cgi?id=119064

So in this case, Iíd argue that matching the semantics of TypedArrayViews (which devs will have to be familiar with just to use this API) is more important than baking subtle performance improvements into the spec.  (And in my ideal world, we would use TypedArrayView semantics literally. I.e., float32View.set(audioBuffer.channel[0]). But thatís for another day. ;-) )

-Jer
Received on Thursday, 12 September 2013 18:49:49 UTC

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