The AudioContext itself is not the source of the white noise. It just causes the DAC (sound card) to power on, which probably emits some noise by itself.
I've always wondered if a browser, the OS's sound server etc. can distinguish between "silence being played" and "nothing being played".
The difference really matters in some cases, e.g. for Bluetooth audio devices supporting multiple sources picking the correct one (looking at Bose's annoying implementation here), avoiding battery drain such as here etc.
Does anybody know if these APIs can even theoretically distinguish receiving all zero bytes from not receiving any bytes, or are the interfaces usually things like ring buffers etc. where the server literally might not be able to know if the client pushed new zero samples or if it's just playing back the old ones over and over again etc.?
Generally speaking yes, they are different. One pattern is that you do something to create a source of audio, and the layer below you starts handing you buffers to fill. With each buffer you send back you can indicate if you want to keep getting called with fresh buffers — if not, the calls stop until you poke something to resume them.
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.
It definitely is possible to detect and, in cases where this is desirable, the lower layers do do that.
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.