New issue
Advanced search Search tips

Issue 650886 link

Starred by 1 user
Status: Duplicate
Merged: issue 497573
Owner:
toyoshim@chromium.org
Closed: Oct 2016
Cc:
rtoy@chromium.org
hongchan@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Chrome seems to grab MIDI devices and not release them until exiting all chrome entirely

Project Member Reported by shawnsingh@chromium.org, Sep 27 2016 
TL;DR:
I suspect that Chrome may be grabbing access to my MIDI keyboards and never releasing them until exiting Chrome.  As a result, when I open my audio sequencer separate from chrome my midi devices don't work.

Question #1:
In what situations do midi devices get grabbed?

Question #2:
Is there any kind of about:midi page?  Is it possible to manually release midi devices somehow, or at least see which midi devices chrome sees and is using?

Things that I have tried to get some insight about the problem:

(1) After using chrome for about a day, my sequencer cannot load midi.  Then if I close chrome and restart my sequencer, midi seems to work again on my sequencer.

(2) If I restart chrome, and then restart my sequencer, midi also seems to work on my sequencer.  That suggests that chrome isn't blindly grabbing any midi devices.  But somehow after a day of use, some website may have grabbed it.

(3) If I visit a web MIDI demo, use my device, and then close the tab (expecting that would release the midi keyboard), then I open my sequencer, midi still does not work.  Instead I have to quit chrome to release the midi device.

This problem has tripped me up very badly!  I thought I was having some deep system / MIDI driver issue and rebooting a lot.  It would be great if this experience can be improved somehow =)

Google Chrome	53.0.2785.116 (Official Build) m (64-bit)
Revision	3f9c628bfd1de2c62de1ea41d0707d06cc760061-refs/branch-heads/2785@{#886}
OS	Windows 
Blink	537.36 (@3f9c628bfd1de2c62de1ea41d0707d06cc760061)
JavaScript	V8 5.3.332.45
Flash	23.0.0.166
User Agent	Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Comment 1 by sbarn...@gmail.com, Oct 26 2016 

I believe that the problem I'm about to describe started in version 53. I'm adding my comment to this issue since my problem could/might be related to the one mentioned above. It seems that Chrome is failing to release an audio driver after a tab with audio is closed.

This is the problem: Windows 10 is showing an audio stream in use and this is preventing Windows 10 from going to sleep.  This is normal behavior since you don't want Windows sleeping if your streaming audio. However, I think Chrome is sending Windows the info regarding the audio stream when all I have open is an empty Chrome tab. There is no web site displayed or any audio streaming and Windows still indicates that an audio stream is in use. I have no other programs running. I just have Chrome running. Also, if I close Chrome, Windows no longer displays that audio streaming is in use. The indication of streaming always disappears whenever I close Chrome.

This problem is happening on a fairly regular basis. I'm unable to give exact instructions on how to recreate the problem. Sometimes I can stream audio, close the tab (with streaming audio), and verify that Windows is not indicating audio streaming. There are other times when I stream audio, close the tab (with streaming audio), and verify that Windows is showing audio streaming when all I have open is an empty tab in Chrome.

Attached Picture:

picture1: Chrome running one empty tab. Windows is showing that audio is streaming. Windows will not sleep.

picture2: Chrome has been closed completely. Windows is showing that no audio streams are present. Windows will now sleep.


My version info:

Google Chrome Version: 54.0.2840.71 m (64-bit)
OS: Windows 10 - 1607 (10.0.14393.321)
picture1.png
15.3 KB View Download
picture2.png
10.9 KB View Download

Comment 2 by hongchan@chromium.org, Oct 26 2016

Cc: hongchan@chromium.org
Owner: toyoshim@chromium.org
They are two different problems.

sbarntho@ Could you please file your issue as a different bug? Then I can properly triage the bug.

I am also assigning this bug to the right owner.

Comment 3 by toyoshim@chromium.org, Oct 26 2016

Mergedinto: 497573
Status: Duplicate (was: Untriaged)
The original report is a known issue that comes from Win32 API's lack of capability for detecting device hot plug and sharing device.
https://bugs.chromium.org/p/chromium/issues/detail?id=497573

We are trying to use new Windows 10 API to solve this problem, but it turns out that the new API does not work with applications that use traditional winmm API, and still almost all applications use it. Also, we recently notice that the new Windows API isn't stable yet, and sometime it gets to be unavailable until OS reboots. We are originally planning to enable this new implementation at m55, but may cancel it.
https://bugs.chromium.org/p/chromium/issues/detail?id=645403

We may re-prioritize to improve winmm version implementation so that it can release when all MIDIAccess instances are deleted. But it will be after the IPC redesign(mojofication) that I'm now working on is finished.
►

Sign in to add a comment