[mikeash]

Thanks for the info. I was familiar with most of that, but didn't think the difference would be so big. How much of a "safety factor" are we talking about between the ability to handle normal audio and the ability to handle this sort of catastrophic case? In other words, how much would you have to turn down the maximum volume limit? Is it a factor of 2, or 10, or 100...?

If it's a factor of 2, for example, just take the 3dB volume loss and move on.

I don't see why detecting the situation is so hard, though. Build a simplistic model of the amount of energy dumped into the speaker and the amount dissipated, run the audio through that model, and then limit the volume when the amount still in the speaker gets too high. This would let through small amounts and limit large amounts, just like you'd want. For a really simplistic model, run the signal through a high pass filter, integrate the output, then apply a running average to that. 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?

[dpe82]

It's hard to know. Speakers are insanely complex beasts whose electrical reactance changes depending on the signal. To simplify things we use measures like RMS current ratings for amplifiers because if you put a sine wave through a speaker they tend to approximate a resistive load due to most of the load being air, and we use nominal impedance to describe speakers because while even though for something as simple as a sine wave a speaker's impedance can vary 4x from nominal depending on frequency, it at least gives us something we can reliably measure.

Once the signal is more complex than a sine wave things get crazy. The more frequencies in a signal, the harder it is to model the power draw since different parts of a complex curve cause the speaker to act more like the low resistance inductor it actually is. Discontinuities and areas of constant voltage (both caused by clipping) are the worst, and to make things even more fun the amplifier is part of the system and affects things as well.

But assuming you know a lot about the speaker, the amplifier and the DAC you could probably build a model that works well for simple sinusoidal audio, but that doesn't cause problems anyway. All bets are off for anything more complex.

So instead you're left with a few options: buy reasonable gear and don't play crap audio, play crap audio but massively overbuild your system so you lower the risk of getting into the unknowable danger zone that changes depending on what you're playing, or use a bunch of heuristics on a signal and try to distort it in some way so it's less potentially damaging.

The problem with the latter is since you don't know where the line is it's easy to be overzealous and end up distorting lots of stuff you don't need to. Problem with the middle is you either end up with something much larger and more expensive than you need, or you cripple what you have to give you a wider margin of safety. Problem with the first is apps like VLC make it exceptionally easy to accidentally play crap audio. Pick your poison.

Could Dell spend a couple extra bucks for higher quality components and create a wider margin of safety? Probably yes. But at the same time the VLC developers are being reckless by putting a tool into consumers hands that makes it so easy to play potentially damaging audio signals.

Edit: clarifications

[mikeash]

I don't really get this description of mitigations as "overzealous". Sure, there's going to be some margin there, but that's just good engineering. The rev limiter on my car's engine doesn't kick in right at the critical RPM where everything falls apart, but some amount below. My CPU's thermal underclocking doesn't start right at the temperature where the component fails, but some comfortable distance below. You could argue that both of those are "overzealous" protections that cause me to lose out on performance I could potentially have otherwise, and that's true, but good engineering in this case generally means using a safety factor for these things.

I don't understand how you can blame VLC at all. Technically, Dell shipped a tool right on the machine that makes it just as easy to play potentially damaging audio signals. Internet Explorer could just as easily play a WAV file that's been crafted to destroy the computer's speakers. The correct approach is to remove that ability, not blame a tool that accidentally triggers the problem.

[dpe82]

Dynamic audio power limiting introduces a whole host of audio distortions that would cause your computer to lie to you by not playing what you told it to. Your computer lying to you is a problem in principal I think, but specifically if you're doing any kind of sound editing/composition it's a huge problem because now you can't know if what you're hearing represents what you're creating or if your os or sound card has messed with it somehow.

As I mentioned, Dell could turn down the input volume to their amp/speakers. It doesn't totally eliminate the ability for a user to damage their speakers but it also doesn't create any distortions. I would guess that's what their bios update does. It just makes everything quieter for everyone.

I appreciate the principal that userland code shouldn't be able to damage hardware, but I'd much prefer my computer not lie to me. Now, I'm also not opposed to dynamic power limiters in general. In fact, that's exactly what VLC should be using if they insist on letting users crank things past levels that would otherwise clip. It just doesn't belong in the os or hardware.

[mikeash]

Your computer's already lying to you by piping your audio through crappy speakers. Is the distortion actually going to be worse with a limiter in place?

I really don't understand, why do you think this functionality doesn't belong in the OS or the hardware? To me, you're basically saying that you're OK with giving arbitrary web sites the ability to damage your hardware, since that's effectively what that ends up implying.

[dpe82]

For really bad audio, no. For otherwise perfectly fine audio, yes.

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