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

Re: AudioBuffer mutability

From: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
Date: Tue, 30 Oct 2012 13:56:34 +0530
Cc: Chris Rogers <crogers@google.com>, Joseph Berkovitz <joe@noteflight.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, public-audio@w3.org
Message-Id: <9388747C-0738-4D92-9515-7E4E13AD52E9@gmail.com>
To: robert@ocallahan.org
> At a small cost, you can keep a copy of the buffer on the main thread to satisfy these requirements.

If a buffer were to be read locked once assigned to a source node, it would mean we cannot assign the same buffer to multiple source nodes to trigger multiple voices using the same underlying sample (like with granular synthesis) ... unless an exception is made for sharing buffers between source nodes .. which would raise "what about convolution nodes?" kinds of questions. Can of nasty worms I think.

Furthermore, if the buffer is a fully decoded 5 min mp3 file, you don't want to keep  copying the entire decompressed file every  time you want to play a 2 second snippet from it using a source node.

Write-locking for prevention of weird behaviour is tolerable. Read locking is not.

-Kumar

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

> 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]
> 
Received on Tuesday, 30 October 2012 08:27:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC