W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: Missing information in the Web Audio spec

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 18 May 2012 18:23:42 +0200
To: "Chris Rogers" <crogers@google.com>, "Robert O'Callahan" <robert@ocallahan.org>
Cc: public-audio@w3.org
Message-ID: <op.weiihsjbsr6mfa@kirk>
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?

https://www.w3.org/2011/audio/track/issues/42 is another issue where the  
internal implementation choices of work buffer sizes would give audible  
differences, possibly there are more similar issues.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 18 May 2012 16:24:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 May 2012 16:24:07 GMT