> 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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
