W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 18539] New: System locking protection / warnings

From: <bugzilla@jessica.w3.org>
Date: Sat, 11 Aug 2012 23:12:15 +0000
To: public-audio@w3.org
Message-ID: <bug-18539-5429@http.www.w3.org/Bugs/Public/>

           Summary: System locking protection / warnings
           Product: AudioWG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Audio API
        AssignedTo: crogers@google.com
        ReportedBy: jussi.kalliokoski@gmail.com
         QAContact: public-audio@w3.org

I believe it is currently possible to lock a single-core system with the Web
Audio API, as the processing takes place in a realtime thread that takes

This should never be allowed to happen, especially from a security perspective.
I suggest the following:

The AudioContext should monitor its status in regard of CPU usage and
underruns. If the mechanism should detect that the graph is failing to meet its
deadlines or seems to be locking the system, it should issue an error event on
the AudioContext. This gives the developer a chance to try and scale down the
intensive parts of the graph. There are two possible default actions for the
event I can think of:

 * If not canceled by event.preventDefault(), the graph will become inactive.
If the graph continues to fail to deliver for X times without the developer
letting it become inactive, lower the process priority. This should make little
difference, because the audio is glitching already, but it prevents
evil-intentioned programs from locking the system.

 * Same as above, except that the default action would be to lower the process
priority and to just do it anyway if the developer fails to mend the situation.


Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 11 August 2012 23:12:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC