Re: AudioBuffer mutability

On Tue, Oct 30, 2012 at 5:47 PM, Chris Rogers <crogers@google.com> wrote:

> On Mon, Oct 29, 2012 at 9:12 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> Yes, it would prevent reading the buffers. Why is that a big problem?
>>
>>
> A simple reason for reading a buffer would be to display its data as a
> waveform.  A more complex reason would be to inspect the PCM data in
> JavaScript for analysis, possibly using the information to determine which
> portions of the buffer to play next.
>

At a small cost, you can keep a copy of the buffer on the main thread to
satisfy these requirements.


> Since these buffers can be passed around as function arguments, it would
> be pretty confusing to developers that some of them became unreadable
> because of some previous activity using the buffer.  This implies a
> statefulness to the buffer which is very likely to trip up developers.
>

The same applies to array Transferables in Web Workers, but we made a
conscious decision to accept those issues in order to avoid data races.


> It's not that surprising that you might get unusual results if you modify
> the data at the same moment it's playing, and I've had nobody in the real
> world ever confused or complain about this.  It's just common sense.
>

Unfortunately, also in the real world, we have a lot of experience with Web
developers failing to use common sense and nevertheless expecting
consistent results across browsers and platforms.

Rob
-- 
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]