Re: AudioBuffer channel read/write APIs

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.


On Thu, Sep 12, 2013 at 1:12 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> Hrm, I meant, in copyToChannel and copyFromChannel (both of them.)
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
> On Thu, Sep 12, 2013 at 10:10 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
>> I think in copyToChannel, start should indicate the offset in the channel
>> data living inside the AudioBuffer to start writing into, as opposed to an
>> offset into the source argument, since source can be a view into another
>> ArrayBuffer if needed.
>>
>> With that correction, this seems fine to me.
>>
>> Cheers,
>>
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>>
>>
>> On Fri, Sep 6, 2013 at 9:50 AM, Marcus Geelnard <mage@opera.com> wrote:
>>
>>>  2013-09-06 04:34, Robert O'Callahan skrev:
>>>
>>>   This is what I proposed:
>>>
>>> partial interface AudioBuffer {
>>>   void copyChannelDataTo(long channelNumber, unsigned long start,
>>> unsigned long length, Float32Array destination);
>>> }
>>>
>>>  I agree with Jer that it makes sense to have a corresponding method to
>>> write into channel buffers.
>>>
>>>
>>> Me too.
>>>
>>>
>>>
>>>  We could call it copyChannelData>From but i think that might get a
>>> little confusing. We can also make 'length' optional. So here's my revised
>>> proposal:
>>>
>>> partial interface AudioBuffer {
>>>    void copyFromChannel(Float32Array destination, long channelNumber,
>>> unsigned long start, optional unsigned long length);
>>>   void copyToChannel(Float32Array source, long channelNumber, unsigned
>>> long start, optional unsigned long length);
>>> }
>>>
>>>  In both methods, 'length' defaults to the array's length. An exception
>>> is thrown if start+length is greater than the ArrayBuffer's length or if
>>> the array length is less than 'length'. I put the array first so that the
>>> parameters identifying the channel and the channel data range are together.
>>>
>>>
>>> This sounds perfectly OK to me.
>>>
>>> /Marcus
>>>
>>>
>>>
>>>  I'd like to get this implemented in Gecko ASAP, so please bikeshed in
>>> a timely manner :-).
>>>
>>>  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
>>>
>>>
>>
>