Re: Issues with ROC's proposal

On Wed, Sep 4, 2013 at 8:11 PM, Marcus Geelnard <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.


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


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