Re: AudioBuffer channel read/write APIs

I'm not crystal-clear on the implications of copyToChannel, when the buffer
has been acquired; am I correct in presuming this would cause an
acquisition under the hood, and the modification would only end up
"applied" for future acquisitions?

That sounds super unclear, so let me try an example.

App creates an AudioBuffer, puts data into it, creates a BufferSource and
points it at the AudioBuffer, makes appropriate connections and calls
start().

At some later point in time (prior to the BufferSource completing,
however), app calls copyToChannel to change the data of the AudioBuffer.
 My presumption is that the currently scheduled playback would not take
those changes into account, but any future acquisitions (e.g. app creates
ANOTHER BufferSource pointing to the same buffer) would have the changed
data.  Is that correct?


On Thu, Sep 12, 2013 at 8:56 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Sep 12, 2013 at 5:13 AM, K. Gadd <kg@luminance.org> wrote:
>
>> Arguably no matter the terminology, start/offset are unclear when you
>> have both a source and a destination. IMO either prefix the offset argument
>> (sourceOffset, etc) or allow offsets to be specified for source and
>> destination. Passing both source and destination offsets would make these
>> APIs a lot more useful since they allow you to carve slices out of a much
>> larger buffer, and there's already the length argument. If you just want
>> people to use typed array views for that, probably take out the length
>> argument and just use the length of the source array.
>>
>
> For most uses I could think of, starting at offset 0 of the array was
> fine. How would an offset into the array make this much more useful?
>
> 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  *
> *
>