As one could imagine it's a bit (read: a lot) more complicated than just pausing the AudioContext after some time of silence, but we'll get it fixed regardless, it's possible because others did it. There are tradeoffs we're willing to do.
Source: Firefox implementer of a lot of things around this, editor of the Web Audio API standard.
Just know that most people understand everything you are saying here. Many things to do, finite amount of time.
I have personal experience of Firefox developers going above and beyond to make high-usage sites work for their users. I know first hand the lengths they will go to when issues affect users. Thank you and keep plugging away.
"It's not perfect as resuming takes a little bit of time and it may not always resume, as there are multiple paths to starting audio. But it's good enough for me."
I think many people would be curious to hear about the additional complexity above and beyond "suspend when silent", if there's an already-written thing you could link to.
(I do know that resume-when-playback-starts sometimes causes the first bit of audio to get lost, or all of the audio for short things like notification sounds.)
So I ask: define silence. Define sleep. Because you get it wrong you have a $200 device headed for the landfill.
If one could describe the state of Bugzilla in two sentences, that would be it :P
Thanks for your work, and for talking about the issue on a public forum! It's so critically important that Firefox maintains/increases relevancy. I'm sure it's unbelieveably difficult work given the resources behind Chromium & Blink.
Computers are a really hostile environment for audio, if possible you're always better off getting an external audio interface to put some distance between the analog signal path and any EMI spewing components.
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 ...
Different browser engines and operating systems implement audio processing differently, so if you play a completely inaudible sound and then record it back (from the API not the microphone) you end up with a signature.
You can use that signature to see if the browser is lying about its user agent, running in headless mode, or all sort of other interesting edge cases that are not a real user buying widgets.
https://github.com/fingerprintjs/fingerprintjs/blob/3201a7d6...
The tab doesn't show the "playing" icon, and muting the tab doesn't stop the noise.
Even using the Windows volume mixer to mute Firefox doesn't stop the noise.
Edit: The addon is actually pretty bad for a desktop user since the white noise starting/stopping constantly is far more annoying.
Seems like this is a deeper bug than FF then, no?
Doesnt make much sense in the context of a laptop though, so energy savings make sense there.
On their Windows drivers, you have an option to set the stream as Always On. I wish this was available on macOS as well...
Right now, coreaudiod on my Mac is at 20% CPU with nothing playing whatsoever :( I'm close to switching to another browser until this is fixed, as it's really ruining battery life for me, but I really don't want to give up Firefox over something seemingly so trivial.
Update: This seems to be a related but different bug.
Basically after detecting silence for 30 seconds or so it switches from a sink backed by the OS audio device to a null sink.
Note: Since this uses a different clock than the audio device we have received some reports that when the context is finally used there can be some distortion at specific tones. The workaround is for sites to use the suspend resume API mentioned in the article.
Firefox 134.0.1 on MacOS here, I don't hear anything.
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.?
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.
You almost certainly don't want every browser tab gaining exclusive address to your sound hardware, for example, which would include things like volume control. It also would make mixing sound from multiple applications/tabs impossible, which is arguably a must-have.
