Re: AudioBuffer mutability

Robert,

Some implementors may want to go the extra mile, in the way you suggest or some other way, and that would be laudable if it doesn't hurt performance too much. But I would be cautious about elevating this buffer-insulation policy to a hard requirement at this time, before we all understand the landscape better.

I can't envision many of the things others will do with the API. And I sense from the questions you asked me that you might not have anticipated some of the legit reasons for reading and writing channel data. I suppose I am saying that overprotecting users, like underprotecting them, can also be bad for an API's evolution, and can make some very useful things impossible in an unintended way.

Best,

…Joe

On Oct 30, 2012, at 8:14 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Wed, Oct 31, 2012 at 10:17 AM, Chris Rogers <crogers@google.com> wrote:
> But we're talking about copying potentially megabytes of data.  This is inefficient, especially on resource-constrained mobile devices.
> 
> OK, so to be precise the scenario you're worried about is:
> -- Application creates a large AudioBuffer
> -- Application plays the AudioBuffer
> -- While playing, the application calls AudioBuffer.getChannelData() and reads the data (but does not modify the data, since you've said applications don't modify AudioBuffers while playing them)
> Is that right?
> 
> In this case, an implementation can still use copy-on-write to avoid copying, although it's more implementation work. For example, when getChannelData() is called while playing the audio, the implementation could create a new ArrayBuffer pointing at the underlying data and mark the data's virtual memory pages read-only while the AudioBuffer is playing. Then any attempt to modify the data through the ArrayBuffer would send a SEGV signal to the process, which could be handled by making a copy of the ArrayBuffer's data into writeable memory and retrying the operation. The above scenario would not trigger any copying with this scheme; copying would only occur if an AudioBuffer is modified while playing.
> 
> Once again, my position is that this "concurrency" issue is not a real-world problem, and is only a theoretical one.  And we have pretty good evidence that this is the case.
> 
> I think we're still very much in the "early adopter" phase of Web Audio, and we don't yet know much about what an average Web developer might do.
> 
> Also, usage of Web APIs tends to evolve significantly over time. Often, someone will discover a hitherto obscure technique (which may or may not be a good idea, or in accord with the spec) and it will suddenly become very popular.
> 
> I will leave you with this thought:
> http://krijnhoetmer.nl/irc-logs/whatwg/20120329#l-45
> :-)
> 
> 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]
> 

... .  .    .       Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com