Re: AudioBuffer mutability

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.

…Joe

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