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