Web MIDI API back-end (work-in-progress)

content/browser/renderer_host/media/midi_host.cc

Index: content/browser/renderer_host/media/midi_host.cc
diff --git a/content/browser/renderer_host/media/midi_host.cc b/content/browser/renderer_host/media/midi_host.cc
new file mode 100644
index 0000000000000000000000000000000000000000..70a1ef87adc2fc5058f09b71ffbc69f6c068073b
--- /dev/null
+++ b/content/browser/renderer_host/media/midi_host.cc
@@ -0,0 +1,96 @@
+// Copyright (c) 2013 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.
+
+#include "content/browser/renderer_host/media/midi_host.h"
+
+#include "base/bind.h"
+#include "base/bind_helpers.h"
+#include "base/debug/trace_event.h"
+#include "base/process.h"
+#include "content/browser/browser_main_loop.h"
+#include "content/browser/media/media_internals.h"
+#include "content/common/media/midi_messages.h"
+#include "content/public/browser/content_browser_client.h"
+#include "content/public/browser/media_observer.h"
+#include "media/midi/midi_manager.h"
+
+using media::MIDIManager;
+using media::MIDIPortInfoList;
+
+namespace content {
+
+MIDIHost::MIDIHost(media::MIDIManager* midi_manager)
+    : midi_manager_(midi_manager) {
+}
+
+MIDIHost::~MIDIHost() {
+  if (midi_manager_)
+    midi_manager_->ReleaseAccess(this);
+}
+
+void MIDIHost::OnChannelClosing() {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::IO));
+
+  BrowserMessageFilter::OnChannelClosing();
+}
+
+void MIDIHost::OnDestruct() const {
+  BrowserThread::DeleteOnIOThread::Destruct(this);
+}
+
+///////////////////////////////////////////////////////////////////////////////
+// IPC Messages handler
+bool MIDIHost::OnMessageReceived(const IPC::Message& message,
+                                 bool* message_was_ok) {
+  bool handled = true;
+  IPC_BEGIN_MESSAGE_MAP_EX(MIDIHost, message, *message_was_ok)
+    IPC_MESSAGE_HANDLER(MIDIHostMsg_RequestAccess, OnRequestAccess)
+    IPC_MESSAGE_HANDLER(MIDIHostMsg_SendData, OnSendData)
+    IPC_MESSAGE_UNHANDLED(handled = false)
+  IPC_END_MESSAGE_MAP_EX()
+
+  return handled;
+}
+
+void MIDIHost::OnRequestAccess(int client_id, int access) {
+  MIDIPortInfoList input_ports;
+  MIDIPortInfoList output_ports;
+
+  // Ask permission and register to receive MIDI data.
+  bool approved = false;
+  if (midi_manager_) {
+    approved = midi_manager_->RequestAccess(this, access);
+    if (approved) {
+      input_ports = midi_manager_->input_ports();
+      output_ports = midi_manager_->output_ports();
+    }
+  }
+
+  Send(new MIDIMsg_AccessApproved(
+      client_id,

[palmer, 2013/06/19 21:39:15]

Nit: Indent one more space to align with (.

[Chris Rogers, 2013/06/20 17:41:33]

Done.

+      access,
+      approved,
+      input_ports,
+      output_ports));
+}
+
+void MIDIHost::OnSendData(int port,
+                          const std::vector<uint8>& data,
+                          double timestamp) {
+  if (midi_manager_)
+    midi_manager_->SendMIDIData(port, data.data(), data.size(), timestamp);

[piman, 2013/06/20 20:16:20]

High-level question: this runs on the IO thread. Can sending to the midi manager
block? AFAIK MIDI interface data rate is very low (4k/s).
It would be a bad thing for one renderer that does MIDI to block the IO thread
and so block the other renderers, UI, etc.
Is the data directly coming from the page? Can a malicious site feed MBs of data
at once?
If the midi manager buffers the data, is there a risk for a malicious site to
OOM the browser?

[Chris Rogers, 2013/06/21 23:04:11]

According to our offline discussion, For now, I'm simply not allowing sending of
MIDI data for this CL,
and will work on that for a followup CL to address these types of problems.

+}
+
+void MIDIHost::ReceiveMIDIData(
+    int port_index,
+    const uint8* data,
+    size_t length,
+    double timestamp) {
+  TRACE_EVENT0("midi", "MIDIHost::ReceiveMIDIData");
+  // Send to the renderer.
+  std::vector<uint8> v(data, data + length);

[palmer, 2013/06/19 21:39:15]

Yeah, it would seem good to avoid this copy, if possible, by making the function
accept a const std::vector<uint8>&.

[Chris Rogers, 2013/06/20 17:41:33]

At the earliest stages, we start with a pointer to raw data (at the OS-specific
level), so need to take the hit (converting to vector<>) at some point.

+  Send(new MIDIMsg_DataReceived(port_index, v, timestamp));
+}
+
+}  // namespace content