W3C home > Mailing lists > Public > public-xg-audio@w3.org > July 2010

Re: Web Audio API Proposal

From: Eric Carlson <eric.carlson@apple.com>
Date: Wed, 14 Jul 2010 08:16:12 -0700
Cc: Corban Brook <corbanbrook@gmail.com>, public-xg-audio@w3.org
Message-Id: <B05F9D1C-A50B-4539-8DFB-E7C126BF1E2A@apple.com>
To: Chris Rogers <crogers@google.com>, Ricard Marxer Pin <ricardmp@gmail.com>

On Jul 13, 2010, at 3:33 PM, Chris Rogers wrote:

> bufferLength
> In my specification document, there is no such thing as "bufferLength" for an individual AudioNode.  The "event" passed back to the process() method has a "numberOfSampleFrames" attribute which is the same thing as what you're talking about I think.  This value could be an argument to createJavaScriptProcessor, so we'll know it ahead of time.  From then on, it could be guaranteed to never change, so we don't need a notification.
  Instead of having an attribute on the event, why not just use event.inputSamples.length ?

On Jul 14, 2010, at 3:06 AM, Ricard Marxer Pin wrote:
> On Jul 13, 2010, at 3:33 PM, Chris Rogers wrote:
>> channelCount
>> The number of input channels could change (for example, from mono to stereo).
>> So only the channelCount will make a difference to the JavaScriptProcessor, but your question still remains.  Should we have a event notification for such a change or simply require the processor to deal with it on-the-fly.  I'm open to either possibility.
> Well as I said before.  My personal vote goes for an event notification.  That way the process method has no logic about setup or
> reconfiguration of the nodes, and the check is not necessary at each block of data processed.


  If there is an event notification we also need a method so code can query the state in cases where the notification wasn't observed (listener registered after notification posted, etc).


Received on Wednesday, 14 July 2010 15:16:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:58 UTC