Re: [whatwg] Real-time thread support for workers

Hello David,

On Thu, Aug 9, 2012 at 3:54 PM, David Bruant <bruant.d@gmail.com> wrote:

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

Yes, this is something I'm worried about as well. But prior work in native
applications suggests that high priority threads are hardly ever abused
like that. Web is a different place though, but it's worth keeping in mind.
And after all, priority threads offer very little benefits unless the
system is under high stress and the work you're doing is deadline-driven.


> * The last source is your own content competing with itself for CPU.
>

*snip*


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

I'm sorry, not entirely sure I follow... :)


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

Yes. Especially in mobile devices it makes a world of difference when for
example on a single-core phone you have an audio app in the foreground, and
a Twitter client in the background. If the Twitter client decides to update
its content, the audio is most likely to glitch and this is most likely not
the way the user wanted it to go. Here's the discussion thread on AudioWG
[1] and a good article exploring the subject of interaction between audio
and the rest of the system [2].

The gain for audio is so significant that a lot of the working group seems
to think it's a good idea to have a whole lot of (not very modular to be
honest) native DSP nodes that can run in a priority thread just to get the
audio running in a priority thread, and I think priority thread workers is
a way better idea.


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

Yes, that would be ideal. However I fear it's not good enough for audio.

[1] Re: Resolution to republish MSP as a note ::
 * The whole thread:
http://lists.w3.org/Archives/Public/public-audio/2012JulSep/thread.html
[2]
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

Cheers,
Jussi

Received on Thursday, 9 August 2012 13:59:48 UTC