You should retain the reference to the MIDIInput instances in the global scope to keep on notified on incoming messages. Otherwise, it will be GC-ed.

Premature WontFix. Updated example keeps everything on global scope (that's bad practice, btw. SIC):

window.midi = ctx
window.midiInputs.push(input)

Same result, WebMIDI not working on Linux. Don't close tickets you haven't tested.

How do you test the page?

Here is what I did:
1. Visit http://codeflow.org/issues/midi/

---- page content ----
requestMIDIAccess
request midi success
Adding onmidimessage to: name: "Midi Through Port-0" manufacturer: ""
----------------------

2. Send a message through the corresponding output port (Assuming ALSA providing loopback ports are attached here)

Run following script in the console
> midi.outputs.values().next().value.send([0x90, 0x00, 0x00])

---- page content ----
requestMIDIAccess
request midi success
Adding onmidimessage to: name: "Midi Through Port-0" manufacturer: ""
input
----------------------

Alsa loopback works, but the keyboard does not.

lsusb | grep AKAI ->  Bus 003 Device 018: ID 09e8:0076 AKAI  Professional M.I. Corp. LPK25 MIDI Keyboard

aconnect -i ->
client 32: 'LPK25' [type=kernel]
    0 'LPK25 MIDI 1'

aseqdump -p 32 ->
 32:0   Note on                 0, note 59, velocity 122
 32:0   Note off                0, note 62, velocity 127
 32:0   Note off                0, note 60, velocity 127
 32:0   Note off                0, note 59, velocity 127

So clearly the keyboard works, and is connected to alsa correctly, and provides inputs. Yet, nothing shows up in Chrome...

CC: Adam who is a specialist of ALSA.

Is the device only one you have? I want to clarify if this is a device specific issue or not.

Also, if you are interested in, can you try one of Web MIDI enabled pages listed up in the following page?
http://qiita.com/toyoshim/items/760c4653370f0ba11fb1

It's better to check devices with pages that are verified to work fine.

> Is the device only one you have? I want to clarify if this is a device specific issue or not.

It's the only midi device I have.

> Also, if you are interested in, can you try one of Web MIDI enabled pages listed up in the following page?
http://qiita.com/toyoshim/items/760c4653370f0ba11fb1


All of the demos output sound when I press on a button with the mouse. None of them output any sound if I press a key on the Akai keyboard.

Thank you for providing more feedback. Adding requester "toyoshim@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

I tried M-Audio O2 on Ubuntu 14.04.4 LTS/x86_64 just in case, and it just worked.
So the problem seems to be a device specific issue.

Here are my logs of aconnect and aseqdump.

% aconnect -i
client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 20: 'USB O2' [type=kernel]
    0 'USB O2 MIDI 1   '

% aseqdump -p 20
Waiting for data. Press Ctrl+C to end.
Source  Event                  Ch  Data
  0:1   Port subscribed            129:2 -> 130:0
 20:0   Note on                 0, note 55, velocity 23
 20:0   Note off                0, note 55
 20:0   Note on                 0, note 55, velocity 40
 20:0   Note off                0, note 55

MIDIPort.version contains "ALSA library version 1.0.25" and alsactl -v shows version 1.0.27.2.

Adam, do you have any idea, what could happen here?

It could also be distribution or version specific

- Ubuntu 16.04 LTS/x86_64
- alsactl -v -> alsactl version 1.1.0
- cat /proc/asound/version -> Advanced Linux Sound Architecture Driver Version k4.4.0-28-generic.
- dpkg -s alsa-base | grep Version -> Version: 1.0.25+dfsg-0ubuntu5
- dpkg -s libasound2 | grep Version -> Version: 1.1.0-0ubuntu1
- MidiPort.version -> ALSA library version 1.0.25

I tried M-Audio O2 on some other versions, 16.04/x86 and 15.04/x86_64, but it works.
I'm now upgrading 15.04/x86_64 to 16.04/x86_64 so that I can have the same version you tried.

Other possible reasons I could imagine are
 - running Linux on VM, and facing some USB driver related compatibility/stability issues
 - using another ALSA MIDI ready application that obtains device exclusively

> running Linux on VM, and facing some USB driver related compatibility/stability issues

Not running in a vm

> using another ALSA MIDI ready application that obtains device exclusively

Possible. Haven't got any other midi ready software installed. Only thing I could think of is audio-recorder. Wanted to test that theory today, after this wasn't working for 2 days (and trough 3 reboots). But now it works...

I've gotten an ubuntu update in the interim (but no chrome update), but that didn't look like any audio stuff. I'm a bit mystified by this.

I found a possible source of this issue. It's not related to the platform/versions, but this:

If you start chrome with the device plugged in (and reload the test page), it works. If you start chrome with the device not plugged in, plug in the device and reload the test page, it does NOT work.

Chrome does not seem to be able to recognize audio devices that're plugged in while it already runs.

Web MIDI hotplug feature, MIDIConnectionEvent, is working fine on Linux and others, though it's slightly unstable on Windows due to OS limitation.

All my tests were done by plugging a device after Chrome started.

Did you succeed to enumerate your device in such cases you plugged the device later, and the device does not work?

Can you clarify the actual steps in details to reproduce the issue?

Working:

1. Plug device in
2. Start Chrome
3. [OK] Go to http://codeflow.org/issues/midi/, device is enumerated and provides input
4. Unplug device
5. [OK] Reload page, device is no longer enumerated
6. Plug device in
7. [OK] Reload page, device is enumerated again and provides input

Not Working:

1. Unplug device
2. Start Chrome
3. Plug device in
4. [FAIL] Go to http://codeflow.org/issues/midi/, device is not enumerated
5. Unplug device
6. Reload page, device is not enumerated
7. Plug device in
8. [FAIL] Reload page, device is not enumerated

Finished to upgrade my 15.04 to 16.04, and now I'm seeing the same issue even with O2.

I remind an ALSA kernel driver bug that Adam fixed for ChromeOS before.
https://bugs.chromium.org/p/chromium/issues/detail?id=499817

Probably the ALSA that Ubuntu 16.04 uses have the same issue.

Possible workaround that Chrome could is to re-initialize MIDIManager on the second call if the first call is finished with no devices. But, I'm not sure we should have such workaround here.

Adam, what do you think?

This kind of bug has come up a few times. Sorry it's not working!

I have reproduced it exactly on Chrome OS with a KORG nanoKEY2.

Version 52.0.2743.57 beta (64-bit)
Platform 8350.46.0 (Official Build) beta-channel panther
Firmware Google_Panther.4920.24.26

This is a nice console one-liner to do a similar query:
navigator.requestMIDIAccess().then(e => e.inputs.forEach(i=>console.log(i)))

I don't know when this started happening.

I confirmed it does not happen on Mac. It's not a system-level issue on Linux since aseq2json works fine (https://github.com/google/midi-dump-tools/tree/master/aseq2json).

Even with other devices connected, no new devices will be seen once Chrome is running.

Devices still come and go properly so udev seems to be working.

udev isn't working, we're not getting any events from it, only what we enumerate at startup. That would do it.

Oops. A stray _ ruined everything :(

https://codereview.chromium.org/2126023004/

So this seems to be a regression from m51.
I set the milestone to m51 to merge this fix to release branches. This is not critical security bug, but the fix is super simple, 1byte change! I'm not sure if this can pass the criteria to merge to stable channel.

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

commit e74c2a9687c28f2718d71ae6ad9b6153119361c7
Author: agoode <agoode@chromium.org>
Date: Thu Jul 07 06:46:32 2016

Fix initialization of udev in MidiManagerAlsa.

New devices would not be detected on Linux. Worse,
things would get very confused if you disconnected
one device and connected another.

This has been broken for four months, with
crrev.com/17cd1b10ded3a5e730bbcb39c57a6d2f8e16a51e

BUG= 625123 

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

[modify] https://crrev.com/e74c2a9687c28f2718d71ae6ad9b6153119361c7/media/midi/midi_manager_alsa.cc

Thanks, Adam.

I'll handle the merge procedures.

Thanks for doing the review and merges.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

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

commit 279c20325144a6b9a024d4c70e7b3f7417d8f80f
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Fri Jul 08 06:08:22 2016

Fix initialization of udev in MidiManagerAlsa.

New devices would not be detected on Linux. Worse,
things would get very confused if you disconnected
one device and connected another.

This has been broken for four months, with
crrev.com/17cd1b10ded3a5e730bbcb39c57a6d2f8e16a51e

BUG= 625123 

Review-Url: https://codereview.chromium.org/2126023004
Cr-Commit-Position: refs/heads/master@{#404092}
(cherry picked from commit e74c2a9687c28f2718d71ae6ad9b6153119361c7)

TBR=agoode@chromium.org

Review URL: https://codereview.chromium.org/2132993002 .

Cr-Commit-Position: refs/branch-heads/2785@{#54}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/279c20325144a6b9a024d4c70e7b3f7417d8f80f/media/midi/midi_manager_alsa.cc

merged to m53 branch.
requesting merge to m52.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit 7e412ca7e5c332d7823033ebd11331c134e5310f
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Mon Jul 11 06:43:07 2016

Fix initialization of udev in MidiManagerAlsa.

New devices would not be detected on Linux. Worse,
things would get very confused if you disconnected
one device and connected another.

This has been broken for four months, with
crrev.com/17cd1b10ded3a5e730bbcb39c57a6d2f8e16a51e

BUG= 625123 

Review-Url: https://codereview.chromium.org/2126023004
Cr-Commit-Position: refs/heads/master@{#404092}
(cherry picked from commit e74c2a9687c28f2718d71ae6ad9b6153119361c7)

TBR=agoode@chromium.org

Review URL: https://codereview.chromium.org/2135903002 .

Cr-Commit-Position: refs/branch-heads/2743@{#606}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/7e412ca7e5c332d7823033ebd11331c134e5310f/media/midi/midi_manager_alsa.cc

merged to m52 branch.
Actually, I saw an error in the middle of "git cl land", but somehow it seems to be submitted.

Here are logs just in case.
--------
% git cl land                                         [Jul/11(Mon) 03:42:57 PM]
Using 50% similarity for rename/copy detection. Override with --similarity.
Running presubmit commit checks ...

** Presubmit Messages **
--tbr was specified, skipping OWNERS check

Presubmit checks took 1.5s to calculate.

Presubmit checks passed.
Description:
Fix initialization of udev in MidiManagerAlsa.

New devices would not be detected on Linux. Worse,
things would get very confused if you disconnected
one device and connected another.

This has been broken for four months, with
crrev.com/17cd1b10ded3a5e730bbcb39c57a6d2f8e16a51e

BUG= 625123 

Review-Url: https://codereview.chromium.org/2126023004
Cr-Commit-Position: refs/heads/master@{#404092}
(cherry picked from commit e74c2a9687c28f2718d71ae6ad9b6153119361c7)

TBR=agoode@chromium.org

Review URL: https://codereview.chromium.org/2135903002 .
 media/midi/midi_manager_alsa.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Fetching pending ref refs/pending/branch-heads/2743...
From https://chromium.googlesource.com/chromium/src
 * [new ref]         refs/pending/branch-heads/2743 -> refs/git-cl/pending/branch-heads/2743
Cherry-picking commit on top of pending ref...
Pushing commit to refs/pending/branch-heads/2743... It can take a while.
error: failed to push some refs to 'https://chromium.googlesource.com/chromium/src.git'
ERROR:git-retry:Process failure was not known to be transient; terminating with return code 1
Push failed with exit code 1.
To https://chromium.googlesource.com/chromium/src.git
!       HEAD:refs/pending/branch-heads/2743     [remote rejected] (error in Gerrit backend)
Done
Retrying, 1 attempts left...
Fetching pending ref refs/pending/branch-heads/2743...
From https://chromium.googlesource.com/chromium/src
   b034d9b..8b1b896  refs/pending/branch-heads/2743 -> refs/git-cl/pending/branch-heads/2743
Cherry-picking commit on top of pending ref...
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'
Your patch doesn't apply cleanly to ref 'refs/pending/branch-heads/2743', the following files have merge conflicts:

Please rebase your patch and try again.
Failed to push. If this persists, please file a bug.
git cl land  20.97s user 45.34s system 23% cpu 4:44.28 total
--------

The second attempt said "The previous cherry-pick is now empty...", this seems to be because the first attempt succeeded actually even though it failed with exit code 1.

After this, I manually retried all merge processes and noticed that branch-heads/2743 already had the patch.

I'm not sure this could meet the bar for the stable, but let me ask.

[Automated comment] Request affecting a post-stable build (M51), manual review required.

Talked to Takashi@ about the manual verification of this bug and he informed that this bug needs external MIDI devices to verify.

Yes, this needs an external MIDI input device to verify.

What I can say here in terms of code is that we have not modified related code recently and all channels run the same code. So if the fix works on the ToT or Canary, it also should work on other channels including Stable. Fortunately, the fix was very small and trivial one.

It might be better if someone in Web MIDI team or the original reporter can verify the fix on merged channels before merging this to Stable?

I can verify this fix is working on beta.
Version 52.0.2743.75 beta (64-bit)
Platform 8350.55.0 (Official Build) beta-channel panther
Firmware Google_Panther.4920.24.26

Thank you Adam,

pucchakayala: Adam verify the fix on beta. Does this help the review for merging to stable?

http://googlechromereleases.blogspot.jp/2016/07/stable-channel-update.html
Now 52 gets on Stable channel.
Let me withdraw the merge request for m51, and close this.