Web MIDI backend for Windows 10

media/midi/midi_manager_winrt.h

Index: media/midi/midi_manager_winrt.h
diff --git a/media/midi/midi_manager_winrt.h b/media/midi/midi_manager_winrt.h
new file mode 100644
index 0000000000000000000000000000000000000000..cc246266dba22d294b89e4ac73bf8d40907fc306
--- /dev/null
+++ b/media/midi/midi_manager_winrt.h
@@ -0,0 +1,69 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef MEDIA_MIDI_MIDI_MANAGER_WINRT_H_
+#define MEDIA_MIDI_MIDI_MANAGER_WINRT_H_
+
+#include <memory>
+
+#include "base/threading/thread.h"
+#include "base/threading/thread_checker.h"
+#include "media/midi/midi_manager.h"
+#include "media/midi/midi_scheduler.h"

[Takashi Toyoshima, 2016/08/23 08:09:38]

Now we do not need to include midi_scheduler.h, but forward declaration is
enough (and recommended).

[Shao-Chuan Lee, 2016/08/24 09:40:30]

Done.

+
+namespace media {
+namespace midi {
+
+class MIDI_EXPORT MidiManagerWinrt final : public MidiManager {
+ public:
+  MidiManagerWinrt();
+  ~MidiManagerWinrt() override;
+
+  // MidiManager overrides:
+  void StartInitialization() final;
+  void Finalize() final;
+  void DispatchSendMidiData(MidiManagerClient* client,
+                            uint32_t port_index,
+                            const std::vector<uint8_t>& data,
+                            double timestamp) final;
+
+  // Callback from MidiPortManager::OnEnumerationComplete on the COM thread.
+  // Calls CompleteInitialization() when both MidiPortManagers are ready.

[Takashi Toyoshima, 2016/08/23 08:09:38]

If we do not have any negative impact, can we make MidiPortManager subclass too
so that we can make OnPortManagerReady private method?

[Shao-Chuan Lee, 2016/08/24 08:50:32]

Done.

+  void OnPortManagerReady();
+
+ private:
+  // Callbacks on the COM thread.
+  void InitializeOnComThread();
+  void FinalizeOnComThread();
+  void SendOnComThread(uint32_t port_index, const std::vector<uint8_t>& data);
+
+  // Subclasses that access protected members of MidiManager.

[Takashi Toyoshima, 2016/08/23 08:09:38]

note: private?

[Shao-Chuan Lee, 2016/08/24 08:50:32]

Done.

+  class MidiInPortManager;
+  class MidiOutPortManager;
+
+  // COM-initialized thread for calling WinRT methods.
+  base::Thread com_thread_;

[Takashi Toyoshima, 2016/08/23 08:09:38]

It would be better to make this unique_ptr and construct and destruct on the I/O
thread.

[Shao-Chuan Lee, 2016/08/24 08:50:32]

Now I'm using a lock to synchronize between FinalizeOnComThread() and the
destructor, to do this I'll need additional locks. In ALSA and Mac
implementations the threads are also declared as class member, maybe this is OK?

[Takashi Toyoshima, 2016/08/25 06:09:44]

Agreed. I read thread.cc again. So, it seems to reset the thread information on
returning from the ctor. So, it's allowed to run Start() on another thread from
the one ran ctor.

+
+  // Should be instantiated on COM thread.
+  std::unique_ptr<base::ThreadChecker> com_thread_checker_;
+
+  // All operations to MidiPortManager should be done on COM thread.
+  std::unique_ptr<MidiInPortManager> port_manager_in_;
+  std::unique_ptr<MidiOutPortManager> port_manager_out_;
+
+  // |scheduler_| is constructed/destructed on COM thread and used by
+  // DispatchSendMidiData on Chrome_IOThread, a lock is required.
+  base::Lock scheduler_lock_;
+  std::unique_ptr<MidiScheduler> scheduler_;  // GUARDED_BY(scheduler_lock_)
+
+  // Incremented when a MidiPortManager is ready.
+  uint8_t port_manager_ready_count_ = 0;
+
+  DISALLOW_COPY_AND_ASSIGN(MidiManagerWinrt);
+};
+
+}  // namespace midi
+}  // namespace media
+
+#endif  // MEDIA_MIDI_MIDI_MANAGER_WINRT_H_