Implement platform specific MIDI backend for Mac OS X.

Hi Kyle. Would you mind attaching your WIP patches so other people can play around with the prelimenary support?

Sure, will try to do that today. If you want to track development without having to patch from bugzilla, my current dev branch is at https://github.com/qdot/gecko-hg/tree/836897-webmidi

Fixed compilation against v1 set of DOM API patches.

Ok, so here's what I know is missing from mac support at the moment: - Packet timing doesn't work. Need to figure out how to get MIDITimeStamps (which are just host time for mac) into our TimeStamp type. - Device hotplugging doesn't work, because of an issue with how we deal with CFRunLoop. So, as long as everything is plugged in when you start firefox, and you don't particularly care about when you sent anything, or sending things in the future, this patch at least allows you to play with devices.

And adding to that list: - Need to change copyright to chromium, since this is an adaptation of their MIDI core.

I worked on Web MIDI for Chromium, and would love to see it in Firefox. For timestamp code, I recommend not using any of the OS-level timestamp/scheduling stuff. The requirements of Web MIDI don't match well across Mac/Linux/Windows around this aspect. What happened in Chromium was that Mac was implemented first with the native OS scheduling, then Windows and Linux needed to implement their independently. Now for simplicity, we want to move to just one scheduling code path. See https://code.google.com/p/chromium/issues/detail?id=467442

(In reply to Adam Goode from comment #7) > I worked on Web MIDI for Chromium, and would love to see it in Firefox. Hey! I recognized your name from reading the Chromium code. :D > For timestamp code, I recommend not using any of the OS-level > timestamp/scheduling stuff. The requirements of Web MIDI don't match well > across Mac/Linux/Windows around this aspect. What happened in Chromium was > that Mac was implemented first with the native OS scheduling, then Windows > and Linux needed to implement their independently. Now for simplicity, we > want to move to just one scheduling code path. Hmm, yeah, I was wondering about this too. We've actually got a generalized TimeStamp class for cross-platform monotonically increasing timers, which on OS X uses mach_absolute_time at its base. I was thinking about using that for our MIDI timing since it seems like it will "just work" once we get above the platform specifics.

Annnnnnd now that I've read the chromium patch I see what's going on. So you're just having all platforms schedule a task through the MIDIScheduler, versus having just one OS do it natively while the others have to schedule through it. Totally makes sense, I was probably being a little myopic by just looking at the OS X implementation. I was planning on going a similar direction once I got to linux/windows, but should probably just get the implementation over with now. Thanks for the heads up!

We're currently split between OS/non-OS scheduling but trying to consolidate. Separately, I think that using the OS timestamp for incoming events is fine as long as the OS uses the correct clock. ALSA uses a separate clock from the normal monotonic clock so rather than try to synchronize, we just put on a new timestamp. Mac I think is fine.

Making this depend on bug 1135640 since we're doing midi platform specifics in Rust.