Re: Missing information in the Web Audio spec

On Mon, May 21, 2012 at 8:20 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> On Fri, 18 May 2012 19:38:41 +0200, Chris Rogers <crogers@google.com>
> wrote:
>
>  On Fri, May 18, 2012 at 9:23 AM, Philip Jägenstedt <philipj@opera.com
>> >wrote:
>>
>>  On Thu, 17 May 2012 01:36:15 +0200, Robert O'Callahan <
>>> robert@ocallahan.org> wrote:
>>>
>>>  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...
>>>>
>>>>
>>> I think this is a sane approach unless everyone is prepared to support
>>> per-sample processing, which I suspect is not the case. Chris, how large
>>> are the work buffers in your implementation? How large can we make the
>>> limit before it becomes a problem to generate useful, real-world effects?
>>>
>>>
>> Hi Philip, the buffer size we use for rendering is 128 sample-frames.  In
>> our implementation it's a power-of-two size become some of the effects use
>> FFTs, where this makes the buffering easier.  We also like to keep this a
>> relatively small power-of-two size (and would even consider going down to
>> 64) to reduce latency for those audio back-ends which can support it.  For
>> those audio back-ends which don't support it, we simply process multiple
>> work buffers to satisfy one hardware request for more data.
>>
>> I think this size is small enough to allow for a good range of useful
>> real-world delay effects.  I don't want to go larger because of the
>> latency
>> hit.
>>
>
> OK, so it sounds like if it is necessary to allow loops, then the spec
> should require that a DelayNode equivalent to at least 128 samples is used.


It's a little more subtle than this.  If the DelayNode is inside of a loop,
*then* there could be such a restriction.  Otherwise, if the DelayNode is
used in a straight processing chain, then of course the DelayTime can go
all the way down to 0.


> What should happen if there is not? Since AudioNode.delayTime is an
> AudioParam this could change at any time, so it can't be checked only when
> constructing the graph.


That's true.  In that case it will have to be clamped internally during
processing to the minimum delay time allowed.


>
>
> --
> Philip Jägenstedt
> Core Developer
> Opera Software
>