jer.noble at apple.com
Tue Sep 22 16:31:23 PDT 2015
> On Sep 22, 2015, at 11:45 AM, Stéphane Letz <letz at 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...
>>> 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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev