Another pattern is that you push buffers to the layer below you and there’s backpressure to keep you sending at the same rate they’re being played out. In that case you can just stop sending buffers when you have nothing to play.

Your reasons are correct. There are so many layers between an app (or web page) and the physical layer of sound which all burn power; phones and earbuds owe quite a bit of their battery life to shutting down bits of hardware when unused.

EDIT: this reminds me of a WWDC many years ago — Apple got really excited about timer coalescing and added parameters to all the low level timer APIs which let you indicate how much slop you want to allow for each individual timer. Ideally then the OS can keep the CPU asleep for longer and wake it up to do work in batches. Code that deals with real time sound has tight timing requirements and can’t be delayed as easily, so in a timer-coalesced world distinguishing between playing silence and playing nothing has an even bigger power impact.

One example, I remember when Firefox added the "audio playing" tab indicator (back then it was a speaker icon, now it says "PLAYING" underneath the tab title). Initially, the indicator was on every tab that had any audio source active, even if it was silent. That was misleading, because many sites just kept an audio source handy without playing anything meaningful. Later, Firefox changed it so that the indicator would disappear during de-facto silence. You may now notice this e.g. when playing a video that has silent bits - the indicator will disappear during these bits even though the video is playing.

However, in general (not just in browsers, but overall), it may not be desirable to actually preemptively shut off the audio device based on such a detection. Not all audio hardware reinitializes itself instantaneously, and some sounds that one needs to play are meant to be short and immediate. Having a heuristic on a lower-than-application-level shut off the audio device could cause some really annoying skips, since only the application level is able to reliably determine when an active audio source is needed. Unfortunately, that also means that application developers are the ones who need to work with such resources responsibly, which is often not the case.

My first thought was the author should be happy that they don't live back in the bad old days of computing. Audible noise was the norm, even when you were playing audio. At least for PCs with sound cards. I don't recall the situation being quite as bad on other platforms. Modern PCs are much better on this front.

I have vague recollections of a quote from the Computer Chronicles in the mid-1990's. It went to the effect of turning a $2000 computer into a $200 stereo ...