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

Re: Help needed with a sync-problem

From: Chris Wilson <cwilso@google.com>
Date: Fri, 3 Aug 2012 17:03:25 -0700
Message-ID: <CAJK2wqXZxkCNku8icGGUkhAqMavPku5oXAwmYHK2c5YaMY+nzA@mail.gmail.com>
To: Marcus Geelnard <mage@opera.com>
Cc: Chris Rogers <crogers@google.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, public-audio@w3.org, Adam Goode <agoode@google.com>, Peter van der Noord <peterdunord@gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 4 August 2012 00:03:55 GMT