Re: Web Audio API Proposal

On Wed, Jul 14, 2010 at 5:16 PM, Eric Carlson <eric.carlson@apple.com> wrote:
>
> 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 ?
>

The thing is that there are many algorithms that must configure
themselves (sometimes a computationally expensive method) to a given
buffer length.  Therefore this should only be called rarely (at the
beginning and any time there is a change of buffer length).
Additionally the buffer length is something that can highly influence
the latency and being able to select for different applications is
normally important.

>
> 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
>

Yes, indeed.  I think the notification could be a callback to a 0
argument method and it would be up to the user to go look for the
current values of sampleRate, bufferSize, etc...

context.onsampleratechange = reconfigureSamplerate;

function reconfigureSamplerate() {
    currentSamplerate = context.sampleRate;

    // here do the stuff we need to do (recalculate filter coefficients, etc...)
}

Or we could have them all in one single notification:

context.oncontextchange = reconfigureEverything;

function reconfigureEverything() {
    currentSamplerate = context.sampleRate;
    currentBufferLength = context.bufferLength;
    currentChannelCount = context.channelCount;

    // here do the stuff we need to do (recalculate filter coefficients, etc...)
}

I guess the second would be simpler and it would actually be enough.
When a listener arrives late to a notification it can always have a
look to the attributes by its own.

-- 
ricard
http://twitter.com/ricardmp
http://www.ricardmarxer.com
http://www.caligraft.com

Received on Wednesday, 14 July 2010 16:17:34 UTC