Re: Missing information in the Web Audio spec

On Thu, May 17, 2012 at 11:02 AM, Chris Rogers <crogers@google.com> wrote:

> As it stands right now, the Web Audio API makes no claims about whether
> the underlying implementation uses a block-based or per-sample approach.


That is good and we should definitely preserve it.

>From a purist API perspective it really doesn't have to, because in the
> future such performance limitations may become moot.  But until that time
> is reached, practically speaking we may have to spell out some limitations
> (minimum delay time with feedback...).  This is what I would suggest.


So then, one approach would be to specify that in any cycle of nodes, there
should be at least one DelayNode with a minimum delay, where the minimum is
set in the spec. The spec would still need to define what happens if that
constraint is violated. That behavior needs to be carefully chosen so that
later we can lower the minimum delay (possibly all the way to zero) without
having to worry about Web content having accidentally used a too-small
delay and relying on the old spec behavior in some way. (I know it sounds
crazy, but spec changes breaking clearly-invalid-but-still-deployed content
is a real and common problem.)

Alternatively we can set the minimum to zero now, but then we need to write
tests for cycles with very small delays and ensure implementations support
them. If there's a JS processing node in the cycle that will not be
pleasant...

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]