- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Wed, 07 Aug 2013 21:50:19 -0400
- 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". Noah
Received on Thursday, 8 August 2013 01:50:40 UTC