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

Re: Web Audio API Proposal

From: Ricard Marxer Piñón <ricardmp@gmail.com>
Date: Wed, 14 Jul 2010 18:16:44 +0200
Message-ID: <AANLkTimhdYFcmNdpgLUb1MBYkdcAXUh_bjc5yWYUvnJ9@mail.gmail.com>
To: Eric Carlson <eric.carlson@apple.com>
Cc: Chris Rogers <crogers@google.com>, Corban Brook <corbanbrook@gmail.com>, public-xg-audio@w3.org
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.

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

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