[lutusp]

Remember that each technical measure you add to a design represents another (a) cost (b) size/weight, and (c) possible failure mode.

> When the running average surpasses a value that indicates the speaker is reaching its limit, cut the volume. I take it that this doesn't work?

No, it might work, but it's really a question of cost, complexity and represents an added failure mode -- something else that can go wrong.

[mikeash]

In my opinion, it should be impossible to physically damage a computer from user-space code. I'm surprised that this seems to be such a controversial opinion.

Given that, a computer which allows random audio API clients to destroy the computer's speakers is not correctly designed. Certainly, it may add cost, size, and weight, but if that's what you need for correctness, then that's what you need for correctness.

The brakes on a car add cost, size, and weight, but you can't just leave them out because you don't feel like accepting that penalty.

[lutusp]

> In my opinion, it should be impossible to physically damage a computer from user-space code. I'm surprised that this seems to be such a controversial opinion.

I don't find that controversial at all, but as time passes, it seems there are more ways that user activities can bring a computer down. The most obvious way is by sending out-of-bounds signals to storage devices that can erase or even physically damage them, but this example of destroying speakers, even though it should not be allowed to exist, seems plausible also.

[mikeash]

In what scenario can userland code send signals that will physically damage storage devices?

[lutusp]

Over my long career (approaching 40 years) I've seen any number of peripheral devices that responded to bad instructions by tearing themselves to pieces. One example would be a HDD driver that inadvertently ordered the R/W heads to move to a nonexistent location. That's pretty common, and sometimes results from a bug in the code, not anyone's intention.

Another common error is to allow a system power shutdown without parking the HDD R/W heads in a sacrificial area, so subsequent mechanical shocks won't cause the heads to collide with a legitimate data surface. This problem can be caused by insufficient power supply capacity -- a capacity that must detect the power shutdown and allow the head traversal to complete before the remaining power is used up.

Just examples, there are many similar ones.

[mikeash]

I think you may have missed the word "userland", because neither example should be possible outside the kernel.