Re: Dropping AudioBuffer in AudioProcessingEvent?

I'm not sure there's a significant win from doing so, although I guess I'm
okay with it.  None of the descriptive info in AudioBuffer interface is
needed: the .sampleRate is redundant (same as GlobalScope sampleRate), as
is the .length (since it's the length of each of the Float32Arrays) and the
.numberOfChannels (the length of the channelbuffer arrays); duration is
just a nice-to-have (i.e. calculatable from the length and the sampleRate).
 But you'd still need to have a couple of sequences of Float32Arrays, so
you're not really simplifying or enabling fewer objects, just getting rid
of the use of AudioBuffer and dropping a few parameters that don't change.

Current interface:

interface AudioProcessingEvent : Event {    readonly    attribute
double      playbackTime
<http://cwilso.github.io/web-audio-api/#widl-AudioProcessingEvent-playbackTime>;
   readonly    attribute AudioBuffer
<http://cwilso.github.io/web-audio-api/#idl-def-AudioBuffer>
inputBuffer <http://cwilso.github.io/web-audio-api/#widl-AudioProcessingEvent-inputBuffer>;
   readonly    attribute AudioBuffer
<http://cwilso.github.io/web-audio-api/#idl-def-AudioBuffer>
outputBuffer <http://cwilso.github.io/web-audio-api/#widl-AudioProcessingEvent-outputBuffer>;
   readonly    attribute object      parameters
<http://cwilso.github.io/web-audio-api/#widl-AudioProcessingEvent-parameters>;
};


Interface with arrays of Float32Arrays:

interface AudioProcessingEvent : Event {    readonly    attribute
double      playbackTime
<http://cwilso.github.io/web-audio-api/#widl-AudioProcessingEvent-playbackTime>;
   readonly    attribute Float32Array[] inputChannelBuffer
<http://cwilso.github.io/web-audio-api/#widl-AudioProcessingEvent-inputBuffer>s;
   readonly    attribute Float32Array[] outputChannelBuffer
<http://cwilso.github.io/web-audio-api/#widl-AudioProcessingEvent-outputBuffer>;
   readonly    attribute object      parameters
<http://cwilso.github.io/web-audio-api/#widl-AudioProcessingEvent-parameters>;
};

Thoughts from others?


On Wed, Aug 27, 2014 at 6:54 AM, Joseph Berkovitz <joe@noteflight.com>
wrote:

> 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
> <https://github.com/WebAudio/web-audio-api/issues/113>) proposal, and
> most significantly added the ability to create AudioParams on Audio Workers
> (issue #134 <https://github.com/WebAudio/web-audio-api/issues/134>).
>
>  The fork is hosted on my fork (http://cwilso.github.io/web-audio-api/).
>  Start here
> <http://cwilso.github.io/web-audio-api/#widl-AudioContext-createAudioWorker-AudioWorkerNode-DOMString-scriptURL-unsigned-long-numberOfInputChannels-unsigned-long-numberOfOutputChannels>
> 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"
>
>