Re: Help needed with a sync-problem

Citerar Chris Wilson <cwilso@google.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.

Yes, I agree that it's a powerful gun to play with, but certainly  
easier to manage than letting web authors insert scripts into  
kernel-level GFX drivers (GLSL code in WebGL can easily block the  
entire user desktop for seconds).

Also, I believe that we have similar problems with native nodes  
already: Either we don't do CPU usage management, in which case you  
can easily make the real-time thread eat away all CPU with native  
nodes, or we do CPU usage management, in which case we should be able  
to kill off JS nodes and native nodes alike, right?

/Marcus

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