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.

Thoughts?