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

AudioBuffer mutability

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 29 Oct 2012 23:31:02 +1300
Message-ID: <CAOp6jLYxde99hqfMj8HPjZvH2AHYU_0fOs6q783_LJBQORpWOw@mail.gmail.com>
To: public-audio@w3.org
If someone attaches an AudioBuffer to an AudioBufferSourceNode, then calls
start(T) on the node, and then modifies the contents of the AudioBuffer (by
calling getChannelData() and then modifying the returned array), do the
changes affect what will be played by the AudioBufferSourceNode?

If they don't, we have to make a copy of the buffer in the start() call, in
case the buffer is mutated later.

If they do, then we are exposed to race conditions where depending on
exactly where the playback position is when script modifies the array, how
much audio is buffered and how everything is implemented, changes to the
buffer may or may not be played. Even worse, on machines with
non-sequentially-consistent memory (or very aggressive optimizing JS
compilers), some subsets of the modifications may be played while others
are mysteriously ignored.

Both options are undesirable. If AudioBuffer didn't provide direct array
access to its samples, we'd have better options. Is it too late to change
that?

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 Monday, 29 October 2012 10:31:31 UTC

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