[webkit-dev] Using JavaScriptCore in an audio context

[Filip Pizlo]

> On Sep 22, 2015, at 11:20 AM, Stéphane Letz <letz at grame.fr> wrote:
> 
> 
>> Doesn't matter what shape the code is. Parsing and compiling code requires memory allocation. JSC will parse and compile the code lazily, so we will continue to allocate memory after the code has already started executing. 
> 
> OK, but our code already has a similar issue when deployed in a WebAudio API ScriptProcessor node (and that should probably be similar when any kind on "dynamically created" ScriptProcessor is done). We hear a few audio glitches until the code is "warm" I guess (compiled with FTL maybe?).

Possibly.  Compiling with FTL happens concurrently, so the act of compiling shouldn’t cause problems.  The FTL is a speed-up over the lower tiers, but the lower tiers should already be fast enough to give good performance on most programs.

> You can test here :
> 
> http://faust.grame.fr/webaudio/noise.html
> 
> http://faust.grame.fr/webaudio/harpe.html 
> 
> http://faust.grame.fr/webaudio/kisana.html
> 
> It seems FireFox for instance is more robust in this area: less audio glitches at the beginning.

Can you file a bug with exact repro steps?  I played with these and did not hear glitches.  Maybe I used a different version of WebKit or different hardware than you.  Filing a bug with specifics can help make these things clear.

Theoretically, this kind of real-time workload is probably the best argument for an execution environment that doesn’t have a warm-up.  On the other hand, it could just be a silly bug in our engine.  We usually do pretty well at cold code execution.

> 
> So my understanding is that we would be in a very similar case if we directly use JavaScriptCore. Is there any safe way to be sure the JS code is actually compiled before executing it?

No.

> By calling the "compute" code thousand of time outside the audio callback? Or is there any other more reliable trick to do that?

That’s the most reliable.

But I just want to be clear.  The fact that the act of compiling code causes memory allocation is just he tip of the iceberg.  There’s no way to prevent JS execution from allocating, and JS has no guarantees about what operations may lead to memory allocation.  Even “a+b” could allocate even if a and b are both numbers, provided the right conditions are met.

> 
>> 
>> We don't usually make such predictions. It would be useful to know if this API would help your use case. 
>> 
> Yes this API is certainly helpful. 
> 
> Thanks.
> 
> Stephane 
>