Re: Dropping AudioBuffer in AudioProcessingEvent?

Marcus,

I would presently favor keeping AudioBuffer since it includes useful descriptive info and since people have already written code to handle it. Even if the descriptive info is redundant (and I’m not sure it is) we may want to add other attributes in the future, and an array of arrays will not afford that opportunity for extension.

It seems to me that getChannelData() simply becomes a trivial operation and that we remove the verbiage about “acquiring contents of an AudioBuffer” from the spec. The copy() methods can be deprecated but do not need to be broken.

I might have missed some point of discussion in the past, please correct me if I have.

…Joe

On Aug 27, 2014, at 2:49 AM, Marcus Geelnard <mage@opera.com> wrote:

> Hi!
> 
> First off, the interface looks good to me. The wording related to ScriptProcessorNode and AudioProcessingEvent may need to be update though (e.g. in 2.15, AudioWorkerNodes should be mentioned).
> 
> Now to my question: Is now a good time to replace the AudioBuffer attributes in AudioProcessingEvent (inputBuffer, outputBuffer) with arrays of Float32Arrays? Or do we need to keep the AudioBuffer interface for some reason?
> 
> /Marcus
> 
> 
> Den 2014-08-25 17:29, Chris Wilson skrev:
>> I've done some tweaking to the Audio Worker (issue #113) proposal, and most significantly added the ability to create AudioParams on Audio Workers (issue #134).
>> 
>> The fork is hosted on my fork (http://cwilso.github.io/web-audio-api/).  Start here to review the creation method, and the bulk of the text begins at http://cwilso.github.io/web-audio-api/#the-audio-worker.
> 
> 
> -- 
> Marcus Geelnard
> Opera Software



.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"