Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BASE: Move CoreMIDI to end of list to speed up finding the right device #2193

Merged
merged 1 commit into from May 1, 2020

Conversation

@mduggan
Copy link
Contributor

mduggan commented Apr 17, 2020

Doing this as a pull request as I wanted to get a sanity check on it as an idea.

CoreMIDI provides hardware midi device support.

On my MacBook, the first call to MIDIGetNumberOfDestinations() takes around 2
seconds. Using one of the midi devices lower on the plugin list (mt32,
fluidsynth, etc) takes 2 extra seconds on every game start as
MidiDriver::getDeviceHandle() enumerates all the plugins to find the right one,
and hits CoreMIDI first.

This change simply moves CoreMIDI to the bottom of the list. It will still
take 2 extra seconds when opening the options box, but that's a rare operation
relative to starting games.

CoreMIDI provides hardware midi device support.

On my MacBook, the first call to MIDIGetNumberOfDestinations() takes around 2
seconds.  Using one of the midi devices lower on the plugin list (mt32,
fluidsynth, etc) takes 2 extra seconds on every game start as
MidiDriver::getDeviceHandle() enumerates all the plugins to find the right one.

This change simply moves CoreMIDI to the bottom of the list.  It will still
take 2 extra seconds when opening the options box, but that's a rare operation
relative to starting games.
@criezy
Copy link
Member

criezy commented Apr 26, 2020

I guess the change is fine. I don't have any hardware MIDI devices myself, and I don't see any delay coming from the MIDIGetNumberOfDestinations() call. So I can't really comment further.

@mduggan
Copy link
Contributor Author

mduggan commented Apr 26, 2020

Interesting! I tried to debug this a bit more - I'm still not sure what causes the delay on my system, and I also don't have any hardware MIDI. When I look in the Console when the MIDIGetNumberOfDestinations call happens, I see messages like this:

default	14:30:29.919625+0900	MIDIServer	MIDIServer.mm:356:FullInit: MIDIServer [56473] starting
default	14:30:29.919703+0900	MIDIServer	MIDIServer.mm:371:FullInit: Preparing to initialize driver plugins ...
default	14:30:29.928421+0900	MIDIServer	MIDIServer.mm:374:FullInit: Driver plugins initialized.
... ~2 seconds later ...
default	14:30:32.011887+0900	MIDIServer	MIDIServer.mm:434:FullInit: Creating XPC Notifier...
default	14:30:32.012142+0900	MIDIServer	MIDIServer.mm:687:XPCInitialize: NOTICE: BLE XPC service listener is receiving notifications.

Between those messages, the app is beachballing. This is a new Macbook Air with 10.15.4. Given the BLE message I thought disabling bluetooth might help, but it didn't make any difference. I thought it might be the debugger or something, but a release build of 2.1.2 does the same thing. I also added some timing around the call to confirm .. this was the output:

MIDIGetNumberOfDestinations took 2116 millis!
MIDIGetNumberOfDestinations took 0 millis!
MIDIGetNumberOfDestinations took 0 millis!
MIDIGetNumberOfDestinations took 0 millis!
MIDIGetNumberOfDestinations took 0 millis!

So maybe something changed in 10.15 or with new hardware that's causing the issue.. either way the workaround is fairly safe I think. I'll play with the API a little bit more and see if I can find another fix, but for now this should be ok to merge too. Will leave open for any other comments and merge next week.

@criezy
Copy link
Member

criezy commented Apr 26, 2020

I double checked on my 2012 Macbook Pro running on macOS 10.15.2. I do indeed see a delay on the first MIDIGetNumberOfDestinations call, but it is about half of what you see (around 1030ms), and given its age this laptop tends to be a bit slow overall compared to recent ones.

@mduggan
Copy link
Contributor Author

mduggan commented May 1, 2020

I played with the API a bit more, but didn't come up with any magic.

I think the ideal way to fix this is probably to start a new thread to make a dummy call to this function ahead of time to ensure the MidiServer gets started, but that's a lot more work to implement and harder to ensure it's correct, so I think for now I'll merge this workaround.

@mduggan mduggan merged commit e5501c7 into scummvm:master May 1, 2020
2 checks passed
2 checks passed
Codacy/PR Quality Review Up to standards. A positive pull request.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
whiterandrek added a commit to whiterandrek/scummvm that referenced this pull request May 9, 2020
…ce (scummvm#2193)

CoreMIDI provides hardware midi device support.

On my MacBook, the first call to MIDIGetNumberOfDestinations() takes around 2
seconds.  Using one of the midi devices lower on the plugin list (mt32,
fluidsynth, etc) takes 2 extra seconds on every game start as
MidiDriver::getDeviceHandle() enumerates all the plugins to find the right one.

This change simply moves CoreMIDI to the bottom of the list.  It will still
take 2 extra seconds when opening the options box, but that's a rare operation
relative to starting games.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.