Le 09/08/2012 02:20, Jussi Kalliokoski a écrit :
Hello there!
On W3C AudioWG we're currently discussing the possibility of having web
workers that run in a priority/RT thread. This would be highly useful for
example to keep audio from glitching even under high CPU stress.
There are 3 sources of potential CPU stress.
* One is external to the web browser (other programs) and obviously web
content shouldn't be allowed to have any influence on that.
* One is in the web browser, but not the audio content you wish wasn't
glitching (other tabs/different origin iframes). Once again, I don't
think it's a good idea to have content influencing other content CPU use
(otherwise, all content will decide to go on high priority for anything,
which defeats the purpose).
* The last source is your own content competing with itself for CPU.
One question I have is whether different parts of your own content (like
different workers) should declare which priority should be given or
whether the application should be written in a way that is resistant to
high CPU stress (e.g. doing few work besides audio work).
Since the only relevant case for priorities is the third one, I'd like
to question the relevance of the use case.
Is implementing per-browsing-content web worker priority worth the
result? Will we be able to really notice an improvement in the audio
quality that often?
I would be more in favor of browsers sharing with content how busy the
CPU is (in a way or another) so that the content shuts down things
itself and decides programmatically what is worth running and what isn't.
David
