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 Piñón 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). eric
Received on Wednesday, 14 July 2010 15:16:46 UTC