Have you disabled your extensions when running this test?

I haven't.

chrome://extensions shows three installed:
- Google Docs 0.9 (aohghmighlieiainnegkcijnfilokake)
- Google Sheets 1.1 (felcaaldnbdncclmgdcncolpebgiejap)
- Google Slides 0.9 (aapocclcgogkmnckokdopfmhonfmgoek)

I've disabled all three for now. I'll report back on the bug if/when the problem recurs. If it does, anything you'd like me to retrieve from a symptomatic instance?

If there is a controller listed in chrome://media-internals it should have the tab title of the owner in the key value pairs. If you can post that it'd be useful for tracking down the culprit.

There were no controllers listed, unfortunately.

Hmm, reporting the parameters of the stream might allow us to make a guess about the owner.

no response from bug opener for > 3 weeks. 
mdriley@gmail.com, can you provide info. as requested in #3?

I provided the answer to #3 in #4 (in the original report, actually).

This hasn't happened since, though. If it does recur, can I get any more information by attaching WinDbg than I can from chrome://network-internals?

er, chrome://media-internals

Thank you for providing more feedback. Adding requester "yiningc@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

not repro as per #7. resolve for now. Please go ahead re-activate this bug if you see this issue again. 

I can now repro this 100% by leaving Gmail open in a tab for a few hours.

Chrome 54.0.2840.71 with all extensions disabled.

Still happy to attach WinDbg and extract useful information.

Sorry, we need the chrome://media-internals report not a WinDbg trace.

I repro'd the issue, opened a new tab, and closed all other tabs. The process hosting the Gmail tab is dead.


chrome://media-internals

[Players]

Recent Players

render_id: 6
player_id: 0
pipeline_state: kStopped
event: WEBMEDIAPLAYER_DESTROYED

render_id: 6
player_id: 2
pipeline_state: kStopped
event: WEBMEDIAPLAYER_DESTROYED

render_id: 6
player_id: 1
pipeline_state: kStopped
event: WEBMEDIAPLAYER_DESTROYED

[Audio]

Input Controllers
none

Output Controllers
none

Output Streams
none

[Video Capture]

Video Capture Device Capabilities
none


C:\WINDOWS\system32>powercfg /requests
DISPLAY:
None.

SYSTEM:
[DRIVER] High Definition Audio Device (HDAUDIO\FUNC_01&VEN_10EC&DEV_0892&SUBSYS_80862032&REV_1003\4&39b9ec7e&0&0201)
An audio stream is currently in use.

AWAYMODE:
None.

EXECUTION:
None.

PERFBOOST:
None.

ACTIVELOCKSCREEN:
None.

Immediately after closing the browser (or attaching with WinDbg and using .closehandle -a), powercfg no longer shows "An audio stream is currently in use".

Hmm, this is very strange. All streams are destructed since none are listed; that suggests that while we may be destructing chrome's audio streams, some aspect of them is being leaked.

Next time this happens can you attach a WinDbg dump and then navigate to chrome://inducebrowsercrashforrealz -- upon restarting your browser there should be a crash id in chrome://crashes that we can look at.

Adding appropriate restrictions in case the dump has any PII in it.

crash/38567d6b00000000

Ah, sorry, I misunderstood. I'll repro again and actually attach a crash dump.

Attached to browser process and ran `.dump /ma`. Zipped result is well over the 10MB attachment limit, so I put it on Google Drive: https://drive.google.com/open?id=0B9h4lIGb5IUmUzk2VHo5WllvZGM

Meanwhile, I have a report for the Chrome crash but it refuses to upload. Instead it just says "upload requested by user, not yet uploaded".

I've attached the crash report from %localappdata%\Google\Chrome\User Data\Crashpad\reports.

To review:

I repro'd once and used chrome://inducebrowsercrashforrealz to get the crash link in #18.

Then I repro'd again, attached WinDbg, and took the full minidump in #20. Then I crashed that same browser with chrome://etc, but the crash dump I see in chrome://crashes won't upload. So I attached it in #21.

Thanks, the crash link in c#18 doesn't show any WASAPI threads as alive. Will take a look at the WinDbg crash tomorrow when I'm back at my desk.

Spent some time with !htrace to capture a diff in handles before and after. Saw some stacks with "Midi" in them.

Opening this page immediately reproduces the problem: https://webaudiodemos.appspot.com/midi-synth/index.html

Pretty confident the problem is in media::MidiServiceWinImpl.

Yep, it's MIDI.

The main browser loop owns a MidiManager instance that is created on startup and shutdown on exit:
https://chromium.googlesource.com/chromium/src/+/484e19f/content/browser/browser_main_loop.cc#1285
https://chromium.googlesource.com/chromium/src/+/484e19f/content/browser/browser_main_loop.cc#1035

MidiManager is lazy. It doesn't *actually* initialize until a renderer creates a call to MidiManager::StartSession:
https://chromium.googlesource.com/chromium/src/+/484e19f/media/midi/midi_manager.cc#136

EndSession is lazy too. Even if there are no sessions left, it leaves the MidiManager initialized:
https://chromium.googlesource.com/chromium/src/+/484e19f/media/midi/midi_manager.cc#145

MidiManager only actually tears down its state when the browser loop calls MidiManager::Shutdown:
https://chromium.googlesource.com/chromium/src/+/484e19f/media/midi/midi_manager.cc#71

The result is that the MidiManager is "initialized" from the time MIDI is first used until the *entire browser* is torn down.

On Windows, that means we leave a ton of HMIDIIN and HMIDIOUT handles open:
https://chromium.googlesource.com/chromium/src/+/484e19f/media/midi/midi_manager_win.cc#1105

Windows remembers that we have those handles open and helpfully prevents the computer from going to sleep.

I've deleted the crashes above, as they should no longer be useful. The bug can be unrestricted now.

(btw, I'm the reporter. I created the bug with my personal e-mail.)

Hum... Web MIDI keeps devices open by design, but I didn't notice this serious problem. I'm just planning to close handles when all Blink clients are gone, but is it enough? With this my plan, probably when a user opens a page using Web MIDI, a computer would not go sleeping until the user closes the page.

Is there a chrome-side infra to capture the timing to enter into / leave from sleeping?

Related to issue #471793 ?

toyoshim@ you'll need to close the handles if there are no clients -- or at least the handles resulting in powercfg holds. Is it not possible to never open these until a page uses WebMIDI and lazily close them when no more clients are detected?

Also, do MIDI input/output handles provide exclusive access? If so, seems like it would be polite to keep handles only for devices we're actively using, while we're actively using them. Today, we keep open handles for all input/output devices for as long as MIDI is initialized.

Figured out why I was seeing this on sites that weren't obviously using MIDI. It appears at least one ad network is calling requestMIDIAccess to fingerprint the browser: https://web.archive.org/web/20161028013538/https://cdn.adsafeprotected.com/sca.js

Thanks.

>33
Since Windows does not provide any API for MIDI hotplug, we need to keep opening connected device to detect device connection and disconnection. Thus we can correctly understand which device is actually connected and disconnected.
Probably, I need to find another way to emulate hotplug and device identification functionality.

>34
Oh, thank you for catching this information. This will explain our unexpected usage changes that happened a few months ago in the dashboard.

+brucedawson as FYI in case this issue relates to other performance issues we're seeing on windows. (feel free to un-cc if this isn't relevant)

I took a look at the code and it looks like we enumerate open and cache devices when requestMIDIAccess is called. Is that intended and correct behavior?

Yes, that's right. That's a JavaScript call to take a control for all existing MIDI devices.
I checked the usage dashboard. Actually, usage jumped up recently, but it's still about 0.1% - 0.15%.

In terms of browser session, when we shutdown Chrome, about 15% of users have called the requestMIDIAccess today. It was under 1% at Sep/1, but I can see a big jump up to 13% at Sep/19 through 29.

wow :-/

Reading the spec, it seems like ports may be implicitly or explicitly opened. Explicitly opening the port requires a call to port.open(), which I'm assuming is not happening. Implicitly opening a port should happen when a new event handler is assigned to the midi port and it hasn't previously been opened via a call to open().

It seems then that our implementation of requestMIDIAccess is doing too much since neither open() nor setting a handler on the ports has been done.  I'd also expect that closing the ports would be related to events on the port objects themselves (e.g. close(), gc, open(), set/clear a handler).

Btw, for other types of media devices such as microphones or webcams, we try as much as we can to not access the devices if all that's required is enumeration.

 Issue 661435  has been merged into this issue.

>#40

Yes, that is exactly the part of the spec we designed for fixing this problem on windows, but haven't implemented yet. That's my bad.

Anyway, I'd have a quick fix first, then solve the essential design issue next.

Great. Thanks for the update.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/491b24ffbe72a50d3af7846bf9207020fb09049e

commit 491b24ffbe72a50d3af7846bf9207020fb09049e
Author: toyoshim <toyoshim@chromium.org>
Date: Thu Nov 10 18:30:21 2016

Web MIDI: do not keep virtual synth open

To release an internally allocated audio stream, close unsupported
device handles as soon as possible.

This is a short-term fix, and will have an essential fix later.

TEST=powercfg/requests shows no audio stream after Web MIDI is called
BUG= 617086 

Review-Url: https://codereview.chromium.org/2485903002
Cr-Commit-Position: refs/heads/master@{#431297}

[modify] https://crrev.com/491b24ffbe72a50d3af7846bf9207020fb09049e/media/midi/midi_manager_win.cc

The first quick fix was submitted.

The audio stream was consumed by the MS sorftware synthesizer that was blacklisted for Web MIDI for security reason. This patch correctly closes the handle for the synthesizer once it is identified as a blacklisted one.

This will fix the sleep mode problem for most users.

If users have actual musical devices connected, it sill prevents from sleeping until the device is unplugged. I will fix this in the next patch by adding suspend/resume functionalities to the MidiManager so that it releases handles when no clients exist.

Could we merge the fix at #c44 to m55 branch?

[Automated comment] Less than 2 weeks to go before stable on M55, manual review required.

Before we approve the merge to M55, could you please confirm this change is well baked/verified in Canary/Dev and safe to merge to M55? 

Also this has been a known bug for a long time (reported on June 3rd on Chrome 50), can this wait until M56? M55 is VERY close to Stable promotion and bar is VERY high. 

From what I understand from comment 38, this became a much more significant problem in mid-September thanks to changing behavior on the web and now Chrome is keeping 15% of Windows devices awake for no reason. Seems like this meets the bar as a significant power management regression.

Sorry, I noticed crbug.com/667233 today.
At this point, this problem seems to happen because of Win32 API problem, and merging my fix to the M55 might not be safe.

Removing "Merge-Review-55" label based on comment #50. Please request a merge to M56 if needed. Thank you.

ETA for a fix here? This bug routinely keeps my computer from sleeping, and according to comment 38 I may have a lot of company.

Can we pursue a smaller, more targeted fix than the one being tracked in crbug.com/672793?

I believe a fix is already available in version 56 which will be released on the stable channel around the end of the month.

Ah, my mistake! I read comment 50 to say that the fix in https://chromium.googlesource.com/chromium/src/+/491b24ff had a bug, and so I'd assumed it was reverted. Looks like it's still there, though.

Thanks for the fix, and sorry for the noise!

crbug.com/667233 wasn't a new thing, but long-living problems that rarely happen in real use cases, but actually happen inside Win32 APIs randomly.

So, I decided to make m56 go with the patch, and the patch wan't reverted until now.

Let me change new priority since the problem can be fixed in most cases for typical users.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/be814a03409b305b3ddbe54b481de71998d6aad3

commit be814a03409b305b3ddbe54b481de71998d6aad3
Author: toyoshim <toyoshim@chromium.org>
Date: Mon Feb 20 19:07:37 2017

Web MIDI: adding backend to support dynamic instantiation on Windows

This patch implements new backend that supports dynamic instantiation
on Windows. This does not cover all functionalities, but just allow
to enumerate devices and hotplug.

BUG= 497573 ,  617086 , 672793

Review-Url: https://codereview.chromium.org/2704643002
Cr-Commit-Position: refs/heads/master@{#451652}

[modify] https://crrev.com/be814a03409b305b3ddbe54b481de71998d6aad3/media/midi/BUILD.gn
[add] https://crrev.com/be814a03409b305b3ddbe54b481de71998d6aad3/media/midi/dynamically_initialized_midi_manager_win.cc
[add] https://crrev.com/be814a03409b305b3ddbe54b481de71998d6aad3/media/midi/dynamically_initialized_midi_manager_win.h
[modify] https://crrev.com/be814a03409b305b3ddbe54b481de71998d6aad3/media/midi/midi_manager.cc
[modify] https://crrev.com/be814a03409b305b3ddbe54b481de71998d6aad3/media/midi/midi_manager_win.cc
[modify] https://crrev.com/be814a03409b305b3ddbe54b481de71998d6aad3/media/midi/midi_service.cc
[modify] https://crrev.com/be814a03409b305b3ddbe54b481de71998d6aad3/media/midi/midi_service.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e262421e78d33170893fd1985df28658ba45a811

commit e262421e78d33170893fd1985df28658ba45a811
Author: toyoshim <toyoshim@chromium.org>
Date: Fri Feb 24 10:13:14 2017

Web MIDI: device open/close for dynamic manager instantiation on Windows

This patch implements functionalities to open and close devices.
Closing operations will be performed outside the manager instance
so that the manager does not block I/O thread. But it would block
next instance's initialization correctly.

BUG= 497573 ,  617086 , 672793

Review-Url: https://codereview.chromium.org/2701503005
Cr-Commit-Position: refs/heads/master@{#452786}

[modify] https://crrev.com/e262421e78d33170893fd1985df28658ba45a811/media/midi/dynamically_initialized_midi_manager_win.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6d4bb28c8ba6e8bf8f53879aa02f0c823a0aa98d

commit 6d4bb28c8ba6e8bf8f53879aa02f0c823a0aa98d
Author: toyoshim <toyoshim@chromium.org>
Date: Wed Mar 01 05:16:18 2017

Web MIDI: implement receiving for dynamic manager instantiation on Windows

This patch makes input ports work perfectly.

BUG= 497573 ,  617086 , 672793

Review-Url: https://codereview.chromium.org/2701783003
Cr-Commit-Position: refs/heads/master@{#453850}

[modify] https://crrev.com/6d4bb28c8ba6e8bf8f53879aa02f0c823a0aa98d/media/midi/dynamically_initialized_midi_manager_win.cc
[modify] https://crrev.com/6d4bb28c8ba6e8bf8f53879aa02f0c823a0aa98d/media/midi/dynamically_initialized_midi_manager_win.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eaeaadec00a39dcd1c725fc1e5ce1fda7cccd185

commit eaeaadec00a39dcd1c725fc1e5ce1fda7cccd185
Author: toyoshim <toyoshim@chromium.org>
Date: Wed Mar 01 06:36:44 2017

Web MIDI: implement sending for dynamic manager instantiation on Windows

This patch makes output ports work perfectly.

BUG= 497573 ,  617086 , 672793

Review-Url: https://codereview.chromium.org/2698413003
Cr-Commit-Position: refs/heads/master@{#453866}

[modify] https://crrev.com/eaeaadec00a39dcd1c725fc1e5ce1fda7cccd185/media/midi/dynamically_initialized_midi_manager_win.cc
[modify] https://crrev.com/eaeaadec00a39dcd1c725fc1e5ce1fda7cccd185/media/midi/dynamically_initialized_midi_manager_win.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d4acd504da2e43ca94a5fe97d14ec01e0f15a69d

commit d4acd504da2e43ca94a5fe97d14ec01e0f15a69d
Author: toyoshim <toyoshim@chromium.org>
Date: Wed Mar 01 08:40:31 2017

Web MIDI: extract manufacturer names on some devices

This does not help us in most cases on Windows 10, but
let me introduce the same code with the legacy backend.

BUG= 497573 ,  617086 , 672793

Review-Url: https://codereview.chromium.org/2715823003
Cr-Commit-Position: refs/heads/master@{#453884}

[modify] https://crrev.com/d4acd504da2e43ca94a5fe97d14ec01e0f15a69d/media/midi/dynamically_initialized_midi_manager_win.cc

long-term fix was completed.
I will roll out this new implementation behind a field trial flag.
Please check the issue 672793 to track the progress.