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

Re: AudioBuffer mutability

From: Chris Rogers <crogers@google.com>
Date: Mon, 29 Oct 2012 21:47:32 -0700
Message-ID: <CA+EzO0mUEw+5TLfFM3FsEWtqHpqspvMozejT+BWZY1Bq1fY-zw@mail.gmail.com>
To: robert@ocallahan.org
Cc: Joseph Berkovitz <joe@noteflight.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, public-audio@w3.org
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.  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.

To be honest, it's quite a large limitation to remove readability.  I'm not
even very fond of the idea of crippling a buffer's write access.  After
all, an application might have used the buffer to play a sound in the past,
but might wish to modify the data to play another sound at a later time.
 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.


> 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]
Received on Tuesday, 30 October 2012 04:47:59 UTC

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