1145038 - Skipping around in Youtube videos eventually blocks all Windows sound.

Status: RESOLVED DUPLICATE of bug 1134977

(Core :: Audio/Video, defect, P1)

Description

[Caspy7]

Attachment: Memory Report after the sound cut out - Video still open.

Steps for reproduction: 

- Create a Fresh profile
- Open https://www.youtube.com/watch?v=jlSF0dtDRD8
- Pause & unpause to ensure the video is focused
- Use arrow keys to skip forward and backwards. Generally screw around this way for a minute or two.  

Results: 
Eventually the sound cuts out and all additional skips take a long time to load with the video spinner displaying each time.  Pause functionality may also disappear.
Additionally, all Windows audio is now muted/gone. Firefox audio can be regained with a restart, but other applications who attempted audio must also be restarted individually to regain their audio.

I'm using Aurora 38.0a2 (2015-03-17) (32 bit).  Windows 7, 64 bit. 

I'm attaching a memory report on the chance that it's useful.  I also induced a crash: bp-ad98e0b1-73ad-4c83-8e3c-6f28a2150318

This may seem an edge case but I know I've experienced it before (in the last month or two?) *without* such extensive skipping, though I can imagine  someone repeating such actions by skipping through a video/movie to locate a particular scene.

Notably, I reproduced on Nightly, but after multiple tries was unable to reproduce on Beta.

As per my comment in bug 1132594, my GPU sucks and I wish it would burn in a fire, but some day it may actually do that on it's own. No idea if that's somehow involved or if the integrated sound card (that how they work nowadays?) also sucks.

Comment 1

[Matthew Gregan [:kinetik]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=63f692bbe88f

Comment 2

[Matthew Gregan [:kinetik]]

This sounds like the issue Paul mentioned in another Windows audio bug (I can't find the comment right now) where the addition of the device change notification stuff was causing (earlier?) resource exhaustion in the OS audio server process (audiodg.exe?).  If that's the cause here, Paul suggested two ways to improve our behaviour: only register a single observer for device changes, and avoid recreating streams when seeking.

I've pushed an untested patch that attempts to do the former of these to the try server: https://treeherder.mozilla.org/#/jobs?repo=try&revision=63f692bbe88f

The latter is worth doing, but requires a bit more work and has a higher chance of causing regressions.

Paul, is there an easy way to detect the case where we've starved the OS's audio server process?

Caspy7, if you could test the try build (when it completes) and report the results, that'd be much appreciated.

Comment 3

[Matthew Gregan [:kinetik]]

ni? padenot for the question in the previous comment.

Comment 4

[Caspy7]

Yeah, I can test that when it's baked.

Would killing/restarting audiodg.exe (after sound is lost) tell us anything useful?

Comment 5

[Paul Adenot (:padenot)]

Matthew, yes, IAudioClient::Initialize returns AUDCLNT_E_CPUUSAGE_EXCEEDED.

Comment 6

[Paul Adenot (:padenot)]

Also we can reuse streams on seek to fix this, but that may be a bit more involved.

Comment 7

[Paul Adenot (:padenot)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=19527f2e4073

Comment 8

[Caspy7]

Tested the try build, got the same (undesirable) results.

Attempted to kill/restart audiodg.exe but the system wouldn't allow it.

Comment 9

[Trevor Rowbotham [:rowbot]]

Attachment: media_memory_leak.html

I talked to :padenot briefly on irc about this a few months ago and he acknowledged that it was a known issue.  The attached testcase should reproduce this bug easily (its the same one I gave to :padenot on irc).  This bug is not limited to just seeking.  The following actions all seem to cause the memory consumption of the audiodg.exe process to grow without that memory ever being released until the Firefox process is closed:

-Seeking
-Playing a new audio file
-Replaying the same audio file after the ended event has fired

The last time I tested this, I believe the memory consumed by the audiodg.exe process was around 700 MB when Windows stopped producing sound.

Comment 10

[Trevor Rowbotham [:rowbot]]

Looks like you will need to download the testcase I posted since where I'm hosting the audio file doesn't like the testcase being run as a bugzilla attachment or you can replace it with a local file. :(

Comment 11

[Caspy7]

I tested both my original steps for reproduction and the newly attached testcase while keeping an eye on audiodg.exe.  Both cases behaved similarly as memory escalated to about 26MB (26.69 & 26.36 respectively) before the sound cut out.  Thereafter the memory didn't really move until after shutting down Firefox.

I tried the testcase on Chrome for kicks and the memory didn't change the entire time.

Notably, the other day I accidentally induced this by simply skipping forward with the keyboard in a medium length video and Aaron mentioned that his son also induced this. Both are Dell laptops if that counts for anything. Are others widely able to induce this?
Either way, Dell is a pretty common brand and I'm concerned that this could be a common (and confusing/disruptive) annoyance for many users.  
Skipping forward in this manner is probably common usage for some.

Comment 12

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Is this related http://support.microsoft.com/en-us/kb/2670667 ?

Comment 13

[Matthew Gregan [:kinetik]]

Trevor, your bug seems to be slightly different to Caspy7's (could be the same underlying cause, but the behaviour of audiodg.exe is different).  I've just posted a leak fix to bug 1134977 comment 21 that's very likely to fix Trevor's problem.  It *may* fix Caspy7's, but I haven't verified that yet.

That hotfix link is interesting, Anthony, thanks!

Comment 14

[Trevor Rowbotham [:rowbot]]

Thanks for pointing out that bug to me Matthew. I'll be sure to check it out.

When trying to install that hotfix in comment #12 on Windows 7 64-bit the installer fails with "The update is not applicable to your computer."  So, that is not a solution for me at least.

Comment 15

[Caspy7]

I just tried reproducing this using both the attached testcase and my instructions using the build found here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8ae2f49d8829/try-win32/

I could not reproduce it with that build.
audiodg.exe barely went over 20MB and stayed fairly stable.
\o/

Comment 16

[Matthew Gregan [:kinetik]]

Thanks for confirming; I'll make this bug a duplicate of bug 1134977 (where the fix has landed), and I'll open new bugs for the other audio changes I've been working on to alleviate this issue (before the root cause was found).

Comment 17

[Trevor Rowbotham [:rowbot]]

This fixed the issues I was experiencing as well.