The idea of feedback-based <i>userspace</i> software thermal management like this seems suboptimal to me — the failure modes are nasty. (By feedback-based, I mean using V/I sense from the amp.)<p>The goal is to prevent the voice coil from overheating, ever. So some kind of calculation runs at some interval t, and it needs to ensure that, over the upcoming time t, the input to the amp can’t possibly overheat the coil, and of course it can’t use V/I sense data to do understand the upcoming heat input.<p>So, at best, one estimates the coil temperature and comes up with an upper bound on how much heat can be added over time t (either based on worst-case music, e.g. a 0dBFS square wave or based on the actual samples), and either allows the next group of samples to be sent to the amp or not.<p>But this is all a tradeoff with real-time performance and battery life. You want t to be long to minimize performance impact and power consumption, especially if user code is involved. But you want t to be short to maximize the ability to play loud music, especially if you aren’t looking at the actual upcoming waveform.<p>And you don’t want your speakers to burn out of you are doing something CPU intensive and your userspace daemon doesn’t schedule.<p>To me, this all suggests that an in-kernel solution could work a lot better. The kernel is involved in sending samples to the hardware anyway — it has the opportunity to look at those samples <i>right then</i>, calculate the integrated power (could be as simple as the sum of the squares or even just a constant!), and decide whether it’s safe. And fetch the V/I sense data to figure out the status, and reduce the volume if it fails. And if the kernel code pushing samples to hardware stops running for whatever reason, the sound is inherently muted as long as the hardware isn’t configured to loop '90’s broken CD style.