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

Re: Web Audio API Proposal

From: Chris Rogers <crogers@google.com>
Date: Thu, 15 Jul 2010 16:24:08 -0700
Message-ID: <AANLkTim9DP5E1j-L9S0DZ-YNsviXWdewAIvx1tmuVBrv@mail.gmail.com>
To: Ricard Marxer Pin <ricardmp@gmail.com>
Cc: Eric Carlson <eric.carlson@apple.com>, Corban Brook <corbanbrook@gmail.com>, public-xg-audio@w3.org
Just a few comments about the notifications:

I think that for JavaScriptProcessor it might be possible to guarantee that
the "buffer size" never changes once it's created so we may not need a
notification here.


> 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...)
> }
>

I think it would be reasonable to guarantee that the context's sample-rate
never changes once it's created, so we may not need a sample-rate changed
notification.



>
> 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...)
> }
>

The context itself only has sampleRate, the others are specific to other
objects.

For any AudioNode object we may consider wanting to receive a notification
for when the number of channels changes for any of its inputs.  This is
slightly complicated by
an input accepting multiple connections (summing junction), but we can
define the appropriate semantics here.  The question is, what can we do with
this information?
In the JavaScriptProcessor case, we may receive this notification after
processor.onprocess gets called so we always have to check in the onprocess
function anyways,
and the javascript potentially has to be prepared to adapt if it does
change.  Yes, it could be an expensive change but the cost is there whether
we do the change in a
notification, or simply by checking in processor.onprocess.  So, I'm not
sure a notification gives us any benefit.

Chris
Received on Thursday, 15 July 2010 23:24:39 UTC

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