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

Re: TAG feedback on Web Audio

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Wed, 07 Aug 2013 21:50:19 -0400
Message-ID: <5202F95B.9010709@arcanedomain.com>
To: robert@ocallahan.org
CC: Jer Noble <jer.noble@apple.com>, "K. Gadd" <kg@luminance.org>, Srikumar Karaikudi Subramanian <srikumarks@gmail.com>, Chris Wilson <cwilso@google.com>, Marcus Geelnard <mage@opera.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 8/7/2013 5:44 PM, Robert O'Callahan wrote:
> On Thu, Aug 8, 2013 at 8:11 AM, Noah Mendelsohn <nrm@arcanedomain.com
> <mailto:nrm@arcanedomain.com>> wrote:
>     Now ask questions like: how many bytes per second will be copied in
>     aggressive usage scenarios for your API? Presumably the answer is much
>     higher for video than for audio, and likely higher for multichannel
>     audio (24 track mixing) than for simpler scenarios.
> For this we need concrete, realistic test cases. We need people who are
> concerned about copying overhead to identify test cases that they're
> willing to draw conclusions from. (I.e., test cases where, if we
> demonstrate low overhead, they won't just turn around and say "OK I'll look
> for a better testcase" :-).)

Right, but with one caveat: an API like this should have a lifetime of a 
decade or two minimum IMO, so there should be some effort to consider 
what's likely to change in terms of both use cases and hardware. If there's 
no clear vision for that, then one could make the case for leaving a very 
significant performance cushion today: I.e. the API should be implementable 
for today's use cases not just with acceptable overhead, but with 
significant "power to spare".

Received on Thursday, 8 August 2013 01:50:40 UTC

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