- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Mon, 29 Oct 2012 23:31:02 +1300
- To: public-audio@w3.org
- Message-ID: <CAOp6jLYxde99hqfMj8HPjZvH2AHYU_0fOs6q783_LJBQORpWOw@mail.gmail.com>
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