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

Re: Proposal for fixing race conditions

From: Jer Noble <jer.noble@apple.com>
Date: Tue, 16 Jul 2013 18:27:34 -0700
Cc: Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, public-audio@w3.org, WG <public-audio@w3.org>
Message-id: <3A1A4145-0E25-4F52-85C8-E49791C1055E@apple.com>
To: "K. Gadd" <kg@luminance.org>

On Jul 16, 2013, at 1:18 PM, K. Gadd <kg@luminance.org> wrote:

> This claim has been made dozens of times now on the list and I've seen multiple requests for even a single test case that demonstrates the performance impact. Is there one? I haven't seen one, nor a comment to the effect that one exists, or an explanation of why there isn't one.

Isn't this self-evident?  Any solution which involves additional memcopy calls during the normal use of the API will have an inherant and known performance cost at the point of the memcopy.  Additionally, there is the ongoing performance cost of having duplicate, in-memory copies of audio data, as well as the additional GC cost of those extra copies.

That said, it would be very easy to demonstrate: in the hypothetical test case, create a new ArrayBuffer from source data before passing it into the API.  I.e.,

> sourceNode.buffer = buffer

becomes:

> sourceNode.buffer = buffer.slice(0)

-Jer

Received on Wednesday, 17 July 2013 01:29:08 UTC

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