[webkit-dev] Using JavaScriptCore in an audio context

[Stéphane Letz]

> 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.

What version of WebKit/Safari are you using ?

> 
> 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.

I'll try again, but if it is with an older version of Webkit/Safari and you dont' hear the problem then...

> 
>> 
>> 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.

Even in pure asm.js code? So then we would need to go for a more reliable  Audio callback ==> double buffer ==> JS (asm.js) code called in a high priority thread scheme (but not real-time)? (so similar design to what WebAudio worker is supposed to achieve : https://developer.mozilla.org/fr/docs/Web/API/Web_Audio_API#Audio_Workers)

Stephane