Re: AudioBuffer channel read/write APIs

On Sep 12, 2013, at 10:37 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Thu, Sep 12, 2013 at 11:49 AM, Jer Noble <jer.noble@apple.com> wrote:
> On Sep 12, 2013, at 11:27 AM, K. Gadd <kg@luminance.org> wrote:
> 
>> So essentially I think I'm asking for the Web Audio version of a given API to be as expressive and symmetric as the C version would be, where reasonable. This seems like a good opportunity, since it's speccing a new API that basically just exposes two special variants of memcpy.
>> 
>> (That's also why I'm okay with a version that is just one buffer and an offset, since everything else can be expressed via a view, if you ignore the performance consequences)
> 
> 
> FWIW, JSC has been doing a lot of work lately to ensure that the performance implications of creating a new TypedArrayView are as minimal as possible.
> 
> See:
> https://lists.webkit.org/pipermail/webkit-dev/2013-August/025267.html
> https://bugs.webkit.org/show_bug.cgi?id=119064
> 
> So in this case, I’d argue that matching the semantics of TypedArrayViews (which devs will have to be familiar with just to use this API) is more important than baking subtle performance improvements into the spec.  (And in my ideal world, we would use TypedArrayView semantics literally. I.e., float32View.set(audioBuffer.channel[0]). But that’s for another day. ;-) )
>  
> Does that mean you and Kevin are both happy with
> 
> partial interface AudioBuffer {
>   void copyFromChannel(Float32Array destination, long channelNumber, unsigned long startInChannel);
>   void copyToChannel(Float32Array source, long channelNumber, unsigned long startInChannel);
> }
> ?

Speaking for myself, yes, I believe that would be sufficient, and preferable to an API with explicit destination offset and length parameters.  Additionally, I would make the last parameter optional, with a default value of 0.

(The copyToChannel() parameters don't /quite/ match up with TypedArraySet(), as theoretically the "reverse-set()" equivalent would have an `offset` parameter referring to the destination array. I'm fine with that, though.)

-Jer