W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: AudioBuffer channel read/write APIs

From: Marcus Geelnard <mage@opera.com>
Date: Fri, 06 Sep 2013 09:50:18 +0200
Message-ID: <5229893A.5050200@opera.com>
To: robert@ocallahan.org
CC: "public-audio@w3.org" <public-audio@w3.org>
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.


> 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
Received on Friday, 6 September 2013 07:50:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC