Re: Issues with ROC's proposal

2013-09-04 13:08, Robert O'Callahan skrev:
> On Wed, Sep 4, 2013 at 8:11 PM, Marcus Geelnard <mage@opera.com 
> <mailto:mage@opera.com>> wrote:
>
>     2013-09-03 23:54, Robert O'Callahan skrev:
>
>>
>>         2) The getChannelData() method can return a persistent copy.
>>
>>         If you call getChannelData() on an AudioBuffer that is in
>>         use, you will get a persistent copy of the AudioBuffer data
>>         (i.e. modifying the data does nothing to the AudioBuffer, and
>>         the array will never be neutered), which kind of goes against
>>         the purpose of getChannelData(). Again, I find this quite
>>         confusing.
>>
>>         I think that a better solution would be to throw in that case
>>         (or possibly return an empty array).
>>
>>
>>     I just disagree with this point. If you just want to read the
>>     buffer, then having getChannelData always work instead of
>>     sometimes work is a clear win. If you want to write to the
>>     buffer, the idea that modifications will affect all future uses
>>     of the buffer and not any uses currently running makes sense to me.
>
>     Maybe I've misunderstood the semantics? My impression was that
>     sometimes modifications to an array returned by getChannelData()
>     will modify the AudioBuffer, and sometimes it won't (ever). Or are
>     you saying that if you getChannelData() on an "in use" AudioBuffer
>     you'll get a copy of it, and if the AudioBuffer later goes
>     inactive and then yet later is activated again, it would pick up
>     the modifications to the array (and the array would be neutered at
>     that point)?
>
>
> There is no "active"/"inactive" per-AudioBuffer status in my proposal. 
> There are only "acquire the contents" operations that occur at 
> specified times.  Each "acquire the contents" operation takes account 
> of all the modifications to getChannelData() buffers that were 
> performed before the operation, and none of the modifications 
> performed afterward.

Ok, thanks for clearing that up.

>
>
>>         4) Data transfer from JS to an AudioBuffer is implicit.
>>
>>         The data transfer from JS to an AudioBuffer is implicit by
>>         design, rather than explicit. This is confusing, and could
>>         lead to hard-to-find bugs.
>>
>>
>>     I'm not sure what you mean here.
>
>     My point here is that since the data transfer is implemented by a
>     neutering operation, which is carried out at a few different API
>     calls/operations (e.g. AudioBufferSourceNode.start()), it may not
>     be 100% clear to the developer when and why the array disappears.
>     For instance, consider the following:
>
>     convolutionNode.buffer = buffer;
>     var a = buffer.getChannelData(0);
>     [1: write/modify a]
>     [2: analyze a]
>     convolutionNode.connect(context.destination);
>     [3: do some other stuff]
>
>     Now, if you refactor the code so that you move stuff between 2 & 3
>     for instance, or if you comment out parts of the code (e.g. the
>     connect() call) in order to debug or test your code, you may end
>     up having very different results (this is in fact a regression
>     compared to the original shared memory design). If we required an
>     explicit setChannelData() call, I think the situation would be
>     much clearer to a developer (but maybe that's just me).
>
>
> That's a fair point. However, in this case my proposal is at least 
> deterministic. If code operating on the ArrayBuffer 'a' is moved from 
> step 2 to step 3, the code in step 3 will always throw an exception 
> due to operating on a neutered array, in every run on every Web Audio 
> implementation. So I don't think it will be that hard for developers 
> to notice the problem and fix it ... although they may be puzzled the 
> first time they run into it.

Yes, it's deterministic (and hence better), and you may be right that 
this is not much of an issue. Just potentially slightly confusing.

>
>
>>     2) The UA can make AudioContext.decodeBufferData put the new
>>     AudioBuffer in the arrays-neutered state (in the terminology of
>>     https://wiki.mozilla.org/User:Roc/AudioBufferProposal#Implementation_Sketch).
>>     So if it can't share memory, the buffer data will be in the right
>>     place as long as the app doesn't call getChannelData on that
>>     AudioBuffer.
>
>     Did you mean AudioContext.decodeAudioData?
>
>
> Yes.
>
>     I think it would only be logical for it to start in the
>     arrays-neutered state since the most likely use case for such an
>     AudioBuffer is to never be modified.
>
>
> Yes.
>
> Rob
> -- 
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus eanuttehrotraiitny  
> eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha 
> iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  
> tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt 
> hwea lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w *
> *


-- 
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software