Re: Help needed with a sync-problem

On Fri, Aug 3, 2012 at 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.


Hi Marcus, I don't think this would be workable because you really need to
run the web worker as "its own" thread with a distinct message loop for
handling events from setTimeout(), etc.  but a real-time audio thread
cannot be blocked.  For example, the CoreAudio thread callback does not
allow any blocking calls.  I don't agree that the GC issues are minimal,
and garbage collection has always been a big problem for real-time audio.
 Also, there are blocking API calls that can be made in web workers (like
File API I think) which can block for a long time.  Of course, you could
tell developers to avoid these calls, but these would be easy mistakes for
even experienced JS developers to make.  I've tried to make the Web Audio
API easy to use where you don't have to worry about these kinds of pitfalls
and you can mix and match API calls to any other JavaScript API without
worrying about this.  Many people tell me that using web workers is very
difficult with no communications with the DOM or other JavaScript APIs only
available in the main thread.  I still do support JavaScriptAudioNode
processing in web workers, so please don't misunderstand me.  I just don't
want to limit audio to *only* happen there.

That said, I don't want to discourage you from experimenting with
approaches as you mention.  I just don't think they're going to be viable.

Cheers,
Chris



>
>
> /Marcus
>
>
>