This is planned, and important, and we'll fix it hopefully soon, it's long overdue. I'm sorry this hasn't happened yet, it's always a game of priorities that can never satisfy everybody on time. It however ranks fairly high on my personal list.
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.
Please don't take this kind of criticism personally. There was a recent blow up from an open source maintainer because he viewed this kind of criticism as a frustration.
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.
I'm a long time Firefox user and have no intention of changing. I fully agree but want to make an important distinction. Sometimes people are complaining about development work and sometimes people are complaining about priorities. This is definitely the latter and I do not think it necessarily a developer issue. Firefox does have the opportunity to become so much greater, but it does require a lot of work and time. I'd argue, give the developers the time and resources. I know Mozilla has their hands in a lot of pies, but Firefox is probably the most important one, even if it isn't the most revenue generating one. Firefox is the symbol of Mozilla and it needs to be the best. The developers have proven how much they can change things and make things better. The Rust partial rewrite was nothing short of a success. So I want to see that progress continued and to keep pushing in that direction.
Thank for your work, from a Firefox user.
Also, the OP is probably already aware of this:
"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."
For every one person "complaining" there are 999 of us quiet ones out here that use and love your product hours out of every day . I hope devs at firefox can cut through gruff articles with click baity titles and extract nuggets of usefulness from them though.
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.)
I have a record player with bluerooth that doesn't understand 45s exist, even though the manufacturer included the adapter; also Bluetooth drops out during quiet parts, such as those in podcasts or old radio programs or any music made prior to 1997 within reason.
So I ask: define silence. Define sleep. Because you get it wrong you have a $200 device headed for the landfill.
I hope this kind of thing can shoot up the priority queue! Battery-stealing and generally janky behavior is likely the main reason folks stop using a piece of software.
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.
On Linux there are weird audio issues that lead to speaker pop, and sometimes opening a new tab can make the audio running from other tabs permanently distorted and static-y until you reboot. (Not a complaint. I've always wondered if it was a browser or audio system issue.)
When I had this issue, it was fixed by disabling and removing the speech-dispatcher. Something to do with text to speech (I never use it but is sure to be a pain if you do need it) automatically doing things that corrupt the audio stream globally.
It might be that nothing is actually being played, but opening an audio session wakes up your systems DAC/amplifier so you can hear the analog noise floor. In that case the noise is actually always there during playback, you're just more likely to notice it during silence.
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.
I knew about OP's problem for years with discord's piece of shit webapp being the most egregious offender. For my system the sound falls into a low power state and there's an audible pop/click when something wakes it up. Even with the tab silenced and all notifications turned off it would still periodically do this. Other sites that used WebRTC had same problem but not as frequent. I think I worked around the issue eventually by disabling the automatic low power state at the expense of some additional battery consumption.
> Computers are a really hostile environment for audio
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 ...
This kind of thing amazes me. Radio is such a simple, yet omnipresent, technology that even something not made to listen to radio can accidentally catch and play the signal like an actual radio player would. I sure hope it's never going away.
When I was growing up, we lived within 6km line of sight from a powerful AM broadcaster on 660KHZ.
By some stroke of fortune, our woodstove smoke pipe and the tinfoil backed insulation of the house,
Along with the grounded base but rusty bolted on top of the woodstove created some kind of resonant receiver at that frequency. It would generate sufficient voltage to deliver the occasional electrical shock, which was very mysterious because we had no idea how this stove could shock you, even when the mains were turned off.
The mystery of the source of the power was shocks when we built a wire drying rack above the stove, which acted as a sound transducer. With the glove rack, we were treated to 24/7 programming, mostly community oriented stuff like “problem corner”(community issue discussion) bush relay messages for remote listeners outside of telephone reach, “tradio” (call in radio Craigslist, basically), news shows, talk shows, and some occasional music.
To me, it was just completely normal, never having known anything else besides electrocution hazard wood stoves and radio show mitten racks lol. It did fuel a fascination for electronics, though, so by the time I was seven I was an avid reader of popular electronics magazine. Forrest Mims. What a treasure of an engineer.
The websites opening an audio context without using it to play anything are probably doing bot detection.
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.
They definitely thought about it, but fingerprinting is already so easy, and really difficult to stop even if you started the web platform from scratch. Nobody is going to accept "websites can't play any audio because it would make fingerprinting sliiiiiightly easier".
Maybe I'm an extreme outlier, but I don't want 99.99% of websites to be able to make any noise at all. And for the remaining ones I could live without audio too.
Not necessarily. Modern Windows lets you create a new mixer/mediasource separate from the app, so you can have Your regular app sounds then separate media(or notification) sounds.
I use the extension on desktop without problems. I guess it depends on what websites you visit. I would disable the extension for ones that do play/stop sounds a lot.
If the output idles, digital SPDIF signals lose sync. Re-syncing once playback starts is not instant, and you lose the first second of audio or so. I wrote a program that kept open an output withought dumping any data to the line, just to prevent the output from idling.
Doesnt make much sense in the context of a laptop though, so energy savings make sense there.
Oh! I think this explains the issue I had on Android Firefox where every so often my phone would randomly consume 10gb/day in data (costing me $stupid on phone bill). I believe a news site was playing audio and was loading new ads on repeat and the tab never went to sleep because of the audio! I had to switch to chrome because the repeating surprise data bills were becoming silly
I've noticed this, or something very similar (not sure if sites are keeping audio contexts open actually, or if this is Firefox-internal, as it also happens on Youtube and other sites not using the Web Audio API) on macOS a while ago too (i.e. an audio-induced power drain, but no white noise): https://bugzilla.mozilla.org/show_bug.cgi?id=1821102
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.
I don't know the ins-and outs of how audioContext is implemented but it's got a lot in there to be very clever and dynamic, playing a notification chime seems like that feels like drawing an svg with D3 instead of img href *.svg. I wonder if there's a serviceWorker hook that could register simple repeatable stuff like notification handlers much lower down on a more efficient API.
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.
Abstraction layers are hard and have bugs. We should probably figure out a way to reduce the number of abstraction layers. Maybe instead of running the software in a virtual machine with an OS abstraction layer (which is itself a shitty OS), it could compile directly to machine-language instructions and interact with your real OS. You could download this once and run it many times.
This has nothing to do with machine language vs. VMs. And yes, there are abstraction layers here, but for very good reasons:
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.
This is planned, and important, and we'll fix it hopefully soon, it's long overdue. I'm sorry this hasn't happened yet, it's always a game of priorities that can never satisfy everybody on time. It however ranks fairly high on my personal list.
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.
Please don't take this kind of criticism personally. There was a recent blow up from an open source maintainer because he viewed this kind of criticism as a frustration.
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.
I'm a long time Firefox user and have no intention of changing. I fully agree but want to make an important distinction. Sometimes people are complaining about development work and sometimes people are complaining about priorities. This is definitely the latter and I do not think it necessarily a developer issue. Firefox does have the opportunity to become so much greater, but it does require a lot of work and time. I'd argue, give the developers the time and resources. I know Mozilla has their hands in a lot of pies, but Firefox is probably the most important one, even if it isn't the most revenue generating one. Firefox is the symbol of Mozilla and it needs to be the best. The developers have proven how much they can change things and make things better. The Rust partial rewrite was nothing short of a success. So I want to see that progress continued and to keep pushing in that direction.
Thanks for all of your hard work. Firefox is so important.
Thank for your work, from a Firefox user. Also, the OP is probably already aware of this:
"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 would like to become a better use of Firefox by debugging issues I find locally. Any guidance on where to start?
Dev doc index is here, includes links to articles about debugging: https://firefox-source-docs.mozilla.org/
Thank you!
For every one person "complaining" there are 999 of us quiet ones out here that use and love your product hours out of every day . I hope devs at firefox can cut through gruff articles with click baity titles and extract nuggets of usefulness from them though.
Thank you for your words on this, and energy on everything else!
Thank you for your work on this!
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.)
I have a record player with bluerooth that doesn't understand 45s exist, even though the manufacturer included the adapter; also Bluetooth drops out during quiet parts, such as those in podcasts or old radio programs or any music made prior to 1997 within reason.
So I ask: define silence. Define sleep. Because you get it wrong you have a $200 device headed for the landfill.
why do you have a record player with bluetooth in the first place. isn't that against the very concept of an analogue medium?
Big thanks from a Firefox user.
> we'll fix it hopefully soon, it's long overdue. I'm sorry this hasn't happened yet
If one could describe the state of Bugzilla in two sentences, that would be it :P
I appreciate you and everybody else's work on Firefox! Thank you!
I hope this kind of thing can shoot up the priority queue! Battery-stealing and generally janky behavior is likely the main reason folks stop using a piece of software.
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.
Thank you! Your work is keeping the web open.
Thank you for your work and also sharing the status here. There is a bugzilla link to follow the progress of the fix?
On Linux there are weird audio issues that lead to speaker pop, and sometimes opening a new tab can make the audio running from other tabs permanently distorted and static-y until you reboot. (Not a complaint. I've always wondered if it was a browser or audio system issue.)
When I had this issue, it was fixed by disabling and removing the speech-dispatcher. Something to do with text to speech (I never use it but is sure to be a pain if you do need it) automatically doing things that corrupt the audio stream globally.
https://tqdev.com/2021-firefox-ubuntu-crackling-sound
Yeah I’m getting this feedback on video calls. I thought maybe it was related to hibernation or microphone input level resetting to 120%
Thanks! What the article does not tell is why it plays white noise (instead of silence).
It might be that nothing is actually being played, but opening an audio session wakes up your systems DAC/amplifier so you can hear the analog noise floor. In that case the noise is actually always there during playback, you're just more likely to notice it during silence.
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.
I knew about OP's problem for years with discord's piece of shit webapp being the most egregious offender. For my system the sound falls into a low power state and there's an audible pop/click when something wakes it up. Even with the tab silenced and all notifications turned off it would still periodically do this. Other sites that used WebRTC had same problem but not as frequent. I think I worked around the issue eventually by disabling the automatic low power state at the expense of some additional battery consumption.
> Computers are a really hostile environment for audio
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 ...
And don’t forget RFI if a cell phone was close to your speakers. You’d hear a noise right before your phone started to ring!
It was used in some nice electronic music!
Dual Band – GSM (1998): https://www.youtube.com/watch?v=ntKOJdht3t8
Mav – HGP (2005): https://www.youtube.com/watch?v=ZacenNeu4fw
Tatarola – Who Is Calling (2007): https://www.youtube.com/watch?v=hTOyaG7VYKw
I could even hear an actual radio broadcast coming off my speakers whenever they were powered. Maddening!
This kind of thing amazes me. Radio is such a simple, yet omnipresent, technology that even something not made to listen to radio can accidentally catch and play the signal like an actual radio player would. I sure hope it's never going away.
When I was growing up, we lived within 6km line of sight from a powerful AM broadcaster on 660KHZ.
By some stroke of fortune, our woodstove smoke pipe and the tinfoil backed insulation of the house, Along with the grounded base but rusty bolted on top of the woodstove created some kind of resonant receiver at that frequency. It would generate sufficient voltage to deliver the occasional electrical shock, which was very mysterious because we had no idea how this stove could shock you, even when the mains were turned off.
The mystery of the source of the power was shocks when we built a wire drying rack above the stove, which acted as a sound transducer. With the glove rack, we were treated to 24/7 programming, mostly community oriented stuff like “problem corner”(community issue discussion) bush relay messages for remote listeners outside of telephone reach, “tradio” (call in radio Craigslist, basically), news shows, talk shows, and some occasional music.
To me, it was just completely normal, never having known anything else besides electrocution hazard wood stoves and radio show mitten racks lol. It did fuel a fascination for electronics, though, so by the time I was seven I was an avid reader of popular electronics magazine. Forrest Mims. What a treasure of an engineer.
https://en.wikipedia.org/wiki/Forrest_Mims
> [...] bush relay messages for remote listeners outside of telephone reach [...]
That sounds fascinating! What types of messages were these usually?
So and so is going to some place up river, will bring something, so and so died, the funeral is….somebody came is in town until the 29th, etc.
Great story, thanks for sharing!
> You’d hear a noise right before your phone started to ring!
Hah, haven’t thought about that in a long time. That’s the anecdote that feels unbelievable if I hadn’t frequently experienced it myself.
That was an incidental but very useful feature!
Sometimes that was pretty useful though; you could infer a lot about the system's state by listening to the faint hints of bus activity!
Back in the CRT days my speakers would make noise whenever I scrolled a website, lol.
Cool to hear. This should deserve to be a high priority bug. Thanks for your work on firefox.
Thank you for all your work on Firefox!
Thank you!!
The websites opening an audio context without using it to play anything are probably doing bot detection.
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...
Grrr. Browser/Web standard people went crazy with API's and never stopped to think how the world will abuse them to do crap like this.
They definitely thought about it, but fingerprinting is already so easy, and really difficult to stop even if you started the web platform from scratch. Nobody is going to accept "websites can't play any audio because it would make fingerprinting sliiiiiightly easier".
Maybe I'm an extreme outlier, but I don't want 99.99% of websites to be able to make any noise at all. And for the remaining ones I could live without audio too.
Considering which companies are largely responsible for adding these APIs, maybe they did think about how they can abuse them.
There are even already plugins for bots running in the wild that simulate Audio Context to trick the boot detection. Crazy!
can't wait for cloudflare to implement this to further disrupt my browsing freedoms and waste cpu cycles
I'd be surprised if their bot-check interstitials aren't already doing something along those lines. Web Audio has been around for a long time.
Wow, this white noise has been driving me crazy for a long time but I could never track it down.
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.
> Even using the Windows volume mixer to mute Firefox doesn't stop the noise.
Seems like this is a deeper bug than FF then, no?
Not necessarily. Modern Windows lets you create a new mixer/mediasource separate from the app, so you can have Your regular app sounds then separate media(or notification) sounds.
I use the extension on desktop without problems. I guess it depends on what websites you visit. I would disable the extension for ones that do play/stop sounds a lot.
If the output idles, digital SPDIF signals lose sync. Re-syncing once playback starts is not instant, and you lose the first second of audio or so. I wrote a program that kept open an output withought dumping any data to the line, just to prevent the output from idling.
Doesnt make much sense in the context of a laptop though, so energy savings make sense there.
This annoyed me to no end with my FiiO K3 DAC on my Macbook. System sounds like dings etc would basically not play because of the delay.
On their Windows drivers, you have an option to set the stream as Always On. I wish this was available on macOS as well...
Hah yeah I used to do the same thing for my USB DAC, except I just did had `play -qn &` start when I logged in.
That's a much more elegant solution that what I made.
Oh! I think this explains the issue I had on Android Firefox where every so often my phone would randomly consume 10gb/day in data (costing me $stupid on phone bill). I believe a news site was playing audio and was loading new ads on repeat and the tab never went to sleep because of the audio! I had to switch to chrome because the repeating surprise data bills were becoming silly
I've noticed this, or something very similar (not sure if sites are keeping audio contexts open actually, or if this is Firefox-internal, as it also happens on Youtube and other sites not using the Web Audio API) on macOS a while ago too (i.e. an audio-induced power drain, but no white noise): https://bugzilla.mozilla.org/show_bug.cgi?id=1821102
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.
The code in Chromium which handles this suspension is here: https://source.chromium.org/chromium/chromium/src/+/main:med...
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.
I don't know the ins-and outs of how audioContext is implemented but it's got a lot in there to be very clever and dynamic, playing a notification chime seems like that feels like drawing an svg with D3 instead of img href *.svg. I wonder if there's a serviceWorker hook that could register simple repeatable stuff like notification handlers much lower down on a more efficient API.
Should I be able to actually hear something?
Firefox 134.0.1 on MacOS here, I don't hear anything.
no sound for me, but indeed, when I click the button to play the sound on author's demo page, watt consumption increases by ~1
Firefox on Android. I do hear a small white noise!
Thanks, this fixed the frontpage of https://www.dr.dk/
…why is a non suspended AudioCntext that is currently not playing anything emitting white noise though?
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.
I wonder if the same problem happens on Android devices too.
I can already imagine "websites control minds via barely-hearable noise" conspiracies...
Abstraction layers are hard and have bugs. We should probably figure out a way to reduce the number of abstraction layers. Maybe instead of running the software in a virtual machine with an OS abstraction layer (which is itself a shitty OS), it could compile directly to machine-language instructions and interact with your real OS. You could download this once and run it many times.
This has nothing to do with machine language vs. VMs. And yes, there are abstraction layers here, but for very good reasons:
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.
[dead]
[flagged]