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 priority.
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.
I believe it's well understood by browser vendors that it's not acceptable to crash or lock up the machine from the use of any web API. So I think this is really more in the realm of implementation detail, and not part of the specification.
Web Audio API issues have been migrated to Github.
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.