- From: Marcus Geelnard <mage@opera.com>
- Date: Fri, 03 Aug 2012 23:51:02 +0000
- To: Chris Rogers <crogers@google.com>
- Cc: Peter van der Noord <peterdunord@gmail.com>, Chris Wilson <cwilso@google.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Adam Goode <agoode@google.com>, public-audio@w3.org
Citerar Chris Rogers <crogers@google.com>: > On Fri, Aug 3, 2012 at 10:40 AM, Peter van der Noord > <peterdunord@gmail.com>wrote: > >> I agree fully that it won't be what most developers want or need to do, >> the api will be used for games and site music/effects mostly, but creating >> custom nodes would be my primary focus. To be honest, the list of native >> nodes that i wanted to use has thinned out, due to some behaviours and >> implementations that were not appropriate for what i wanted. That's all >> fine by itself, but if i can't recreate them myself... >> >> I personally don't think "a lot of people won't be using custom nodes >> anyway" is a good argument for not implement them correctly. If they add >> lag, i can't use them. >> > > Peter, as Jussi has pointed out. This is a sad fact of life and "not a > bug". If you read more carefully what Jussi says, this lag/latency is not > something we can somehow fix by creating a different API. This is the way > that a real-time audio thread interacting with a main thread (which can > have its own delays such as garbage collection) must be. It's a law of > physics. Chris, if the JS node ran as a worker, what do you think about implementing it in such a way that the JS worker "onaudioprocess" callback was executed directly in the real-time audio thread, using the internal buffer size (128 samples) as a working set, which should avoid the latency problems? I can see some issues (e.g. GC and first-run JIT overhead), but I think that they are either minimal/not-a-real-problem, or solvable. /Marcus
Received on Friday, 3 August 2012 23:51:33 UTC