What you're asking translates to "what do think of let web authors insert script into a high-priority background thread?" That's a bit concerning. On Aug 3, 2012 4:51 PM, "Marcus Geelnard" <mage@opera.com> wrote: > 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 Saturday, 4 August 2012 00:03:54 UTC