W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: AudioBuffer mutability

From: Joseph Berkovitz <joe@noteflight.com>
Date: Tue, 30 Oct 2012 08:49:51 -0400
Cc: Joseph Berkovitz <joe@noteflight.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, Chris Rogers <crogers@google.com>, public-audio@w3.org
Message-Id: <BDD5277E-9536-4A0E-B24D-98A1AD9FE86E@noteflight.com>
To: robert@ocallahan.org
Hi Robert,

Here is the scenario, and it's not hypothetical -- it occurs in our application and I would expect it to occur in others. Musical applications tend to require on-the-fly modifications of previously loaded or processed audio data.

1. Load an AudioBuffer from a media file (note that we didn't generate it so we don't have the samples on hand somewhere else)
2. Play the AudioBuffer via various AudioBufferSourceNodes
3. During live playback, dynamically determine that we need to play a programmatic transformation of the originally loaded media
4. Copy the contents of the AudioBuffer to a new AudioBuffer, applying said programmatic transform to the data
5. Use the new AudioBuffer to generate the transformed output via other AudioBufferSourceNodes

So it isn't OK to altogether remove the ability to obtain a copy of the underlying buffer data on demand. However note that this scenario doesn't require *live• access to the underlying buffers, since it doesn't rely on modifying any AudioBuffer that is actually in use.

For performance reasons, I also dislike the idea of being required to maintain a copy of the loaded data in a separate AudioBuffer that is never played. The audio data could be quite lengthy.


On Oct 30, 2012, at 12:12 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> Yes, it would prevent reading the buffers. Why is that a big problem?
> Rob
Received on Tuesday, 30 October 2012 12:50:24 UTC

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