Open Bug 1165677 Opened 6 years ago Updated 4 months ago

Audio stream remains open when playback paused, preventing power saving/sleep

Categories

(Core :: Audio/Video: Playback, defect, P3)

38 Branch
x86_64
Windows 7
defect

Tracking

()

Tracking Status
firefox79 --- affected

People

(Reporter: u510688, Unassigned)

Details

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.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
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
Component: Web Audio → Audio/Video: Playback
Any ideas, Matthew.
Flags: needinfo?(kinetik)
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.
Flags: needinfo?(kinetik)
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

Hi folks,

Sorry to resurrect an old bug. I've noticed this happening very frequently. I had originally reported it here: https://support.mozilla.org/en-US/questions/1288624 and was directed to this bug.

When running Firefox, I've noticed the following issue that's preventing my computer from going to sleep.

When running Outlook web (email client), if an audio alert occurs, there seems to be a constant audio stream occurring which is then preventing the computer from sleeping. I am able to reproduce this 100% of the time. There is no speaker icon showing on the tab to indicate there is audio playing. This does not occur in Chrome.

To reproduce:

  1. Open an Outlook for web client in Firefox
  2. Receive an audio alert (e.g. new email/meeting alert etc)
  3. In an elevated command prompt, perform a

powercfg /requests

I am seeing the following:

DISPLAY:
None.

SYSTEM:
[DRIVER] Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0255&SUBSYS_10251259&REV_1000\5&26841d0a&0&00)
An audio stream is currently in use.
[PROCESS] \Device\HarddiskVolume9\Program Files (x86)\Mozilla Firefox\firefox.exe
[PROCESS] \Device\HarddiskVolume9\Program Files (x86)\Mozilla Firefox\firefox.exe
[PROCESS] \Device\HarddiskVolume9\Program Files (x86)\Mozilla Firefox\firefox.exe
[PROCESS] \Device\HarddiskVolume9\Program Files (x86)\Mozilla Firefox\firefox.exe
[PROCESS] \Device\HarddiskVolume9\Program Files (x86)\Mozilla Firefox\firefox.exe
[PROCESS] \Device\HarddiskVolume9\Program Files (x86)\Mozilla Firefox\firefox.exe
[PROCESS] \Device\HarddiskVolume9\Program Files (x86)\Mozilla Firefox\firefox.exe

AWAYMODE:
None.

EXECUTION:
None.

PERFBOOST:
None.

ACTIVELOCKSCREEN:
None.

Firefox version: 76.0.1 (32-bit)

Let me know if you need any further info.

Hallo,

same issue as what the_new_mr mentioned.
As soon as I receive an e-mail in outlook, an audio stream is reported in powercfg /requests indefinitely.

Closing outlook's tab seems to stop the audio stream.

This is on Firefox 79.0 (64-bit) on Windows 10

You need to log in before you can comment on or make changes to this bug.