- 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
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 UTC