W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: Help needed with a sync-problem

From: Marcus Geelnard <mage@opera.com>
Date: Fri, 03 Aug 2012 23:51:02 +0000
Message-ID: <20120803235102.1j4w13rv4ckk8kcc@staff.opera.com>
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.

Received on Friday, 3 August 2012 23:51:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC