Re: AudioBuffer mutability

Den 2012-10-31 02:10:59 skrev Joseph Berkovitz <joe@noteflight.com>:

> 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 still have a hard time seeing a legit use case where you need to read &  
write an AudioBuffer that is currently playing, in real-time. It will, no  
matter how you do it, give unpredictable results since the main thread and  
the playback thread are asynchronous. For those use cases you should  
probably be able to find other solutions (typically involving the  
ScriptProcessorNode).

If you only want to read the data while it's playing, I think you can  
either live with a memcpy operation (copying a 10 MB sound clip should  
take only a few milliseconds on most computers/devices). If you want to  
use if for things like real-time visualization, you could keep an extra  
copy of the buffer around to save time (or use the AnalyserNode).

Just my two cents...

/Marcus


> 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
>



-- 
Marcus Geelnard
Core graphics developer
Opera Software ASA