Open Bug 1165677 Opened 6 years ago Updated 4 months ago
Audio stream remains open when playback paused, preventing power saving/sleep
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150513174244 Steps to reproduce: Open Firefox to a page which does not play audio. In an elevated command prompt, ensure that no audio devices are being used using the command "powercfg -requests". Browse to serialpodcast.org and play audio. Use aforementioned command to see that audio device is in use. Then stop the audio on the website and wait 10 seconds. Use the aforementioned command to check if the audio device is still in use. Actual results: The audio device remains in use even though no audio is being played. This prevents the computer from going to sleep. Expected results: The audio device should be released when audio is not being played.
I've done some more tests and found that this problem occurs with some sound devices and not others. Of the 3 on my system, this problem only occurs with one of them. The 2 that work don't seem to have anything in common - I've tried changing sample rate, bit depth, disabling/enabling sound enhancements, etc, and it's had no effect. To reiterate - this bug prevents the entire system from going into standby/sleep mode!
I've re-tested this in FF 38.0.5 with a newly created, untouched, profile and it's even worse. Before, it was intermittent but not it happens reliably. Follow reproduction instruction above but use the following video instead: https://www.youtube.com/watch?v=614OdhFLUUU and then pause it. The audio device is never released, and the system is prevented from going to sleep/hibernation. I also checked the same procedure in Chrome and confirmed it does release the audio device after about 10-15 seconds.
I have confirmed this bug on Windows 7 x64 on the newest Nightly 46.0a1 release. Name Firefox Version 46.0a1 Build ID 20151217030207 User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0 Thank you, Justin
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Untriaged → Web Audio
Product: Firefox → Core
Any ideas, Matthew.
Priority: -- → P2
Other than destroying the media element, there's not really a concept of stopping playback, only pausing in the HTML media API. So we implement this by pausing the audio stream but keeping it alive so we can resume playback quickly and with no audio dropouts. There have been discussions in the past about closing audio streams completely during pause, either immediately or after a timeout, to conserve resources. At that time, I wasn't aware that a paused audio stream would prevent power saving/sleep... the fact that it can makes a more convincing argument for shutting down the audio stream completely when pausing. The 10-15s behaviour of Chrome is interesting - it suggests they may be pausing initially and closing the audio stream after a timeout. That seems like it'd be the best approach for Gecko too. There's a small bit of complexity around handling audio that has been written to the OS audio stream and discarded by the decoder - when shutting down this is lost unless it's buffered in multiple places or redecoded when resuming playback. Note that we already have most of this (e.g. shutting down and redecoding) in place for discarding video decoders when they're idle via the dormant timeout heuristic. It looks like this is only used for MSE, the standalone MP4 decoder, and the OMX decoder right now.
Summary: Sound device not released when audio not being played → Audio stream remains open when playback paused, preventing power saving/sleep
Mass change P2 -> P3
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.