> On Sep 22, 2015, at 11:45 AM, Stéphane Letz <l...@grame.fr> wrote: > >> 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)
The Audio Worker thread will not run at a higher-than-normal priority (see <http://webaudio.github.io/web-audio-api/#the-audioworker-interface>, paragraph 2). The only performance benefit of the Audio Worker is that it will continue to be serviced while the main thread is blocked. -Jer > > Stephane > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
