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

Re: New proposal for fixing race conditions

From: Marcus Geelnard <mage@opera.com>
Date: Fri, 19 Jul 2013 22:51:11 +0200
Message-ID: <CAL8YEv4CfU=JYf7+5z+z1j=g3Z0+cg53p=O9ATxi3F+3Rkj0vA@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>
On Fri, Jul 19, 2013 at 10:07 PM, Jer Noble <jer.noble@apple.com> wrote:

>
> On Jul 19, 2013, at 12:52 PM, Marcus Geelnard <mage@opera.com> wrote:
>
> Also, I think it would be useful to have a more specific version of the
> set operation, in order to be able to update only a sub-part of the
> AudioBufferChannel from a sub-part of the source array (use case: editing &
> updating small parts of a large AudioBufferChannel). It would have to take
> two more arguments, e.g:
>
>
> This is already achievable by creating a new Float32Array “view” onto the
> underlying ArrayBuffer.  I.e. to set ‘buffer' samples (50, 150] with only
> the first 100 samples from ‘array’:
>
> buffer.set(array.subarray(0, 100), 50);
>
> The TypedArray.subarray method involves no copying of the underlying data.
>

True, but I remember having problems with subarray this in the past.
Specifically, it will increase GC activity since even though the subarray()
method uses the same array memory, it still creates another ECMAScript
object. Hard to say where to draw the line: subarray() is more elegant, but
a more detailed set method would be (slightly) more efficient.

/Marcus


>
> -Jer
>
Received on Friday, 19 July 2013 20:51:39 UTC

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