Intermittent initialization issues on macOS High Sierra

[jceipek]

I'm using RtMidi by calling into a .bundle I generated from the latest version of the included C wrapper without any modifications. It mostly works fine, but intermittently I get a MidiInCore::initialize: error creating OS-X MIDI client object (-50) error and then I won't be able to use rtmidi_in_create_default or rtmidi_out_create_default anymore (they fail with the same error) until I forcibly unload the .bundle. Even reconnecting my MIDI device doesn't fix the problem.

Prior to using macOS High Sierra, I wasn't encountering any issues. Note that I am calling rtmidi_out_free and rtmidi_in_free after closing every port I open.

Do you have any suggestions for tracking down the problem?
I'm at a loss for how to debug this, because the initialization seems to go fine until https://github.com/thestk/rtmidi/blob/master/RtMidi.cpp#L626, where MIDIClientCreate returns -50, an error code that doesn't seem to be defined in MIDIServices.h and seems to typically mean "Invalid Parameter".

Could the previous client be sticking around somehow, and if so, how could I determine that and release it if necessary?

[radarsat1]

Hm, I'm not sure how to go about it exactly.. I guess what I would do in this case is cut out the CoreMidi part of the code and produce a minimal example using only CoreMidi that demonstrates the problem, and go to a Mac developer forum. Especially if it's returning undefined errors, it could be an operating system/driver bug that needs to be reported to Apple. (That's just a shot in the dark of course..)

[jceipek]

I just found this post by someone with a similar issue but way more experience with C++ and CoreMidi than me:

https://lists.apple.com/archives/coreaudio-api/2013/Sep/msg00014.html

From the post:

ret = MIDIClientCreate(cname, NULL, NULL, &mclient);

It gives me ret == -50 , which is a (paramErr): error in user parameter list

and

I've resolved this error, it's ok. It was caused by an uninitalised variable.

Could that be what's happening here?

[jceipek]

Also: https://stackoverflow.com/questions/29411341/midiclientcreate-the-operation-couldnt-be-completed-osstatus-error-50

MIDIClientCreate itself will return -50 in only two scenarios:

1. If outClient itself is NULL so in the above you forget to take the address of client.
2. If the MIDI server has an issue getting a process ID back internally

[radarsat1]

It sounds like a driver problem so I don't know if it can be fixed at the RtMidi level. Unfortunately I can't personally reproduce the problem so you'll probably have to do some debugging. Can you find something uninitialized or whatever in the parameters? Can you determine under what conditions this happens? (e.g. only after reading ports? Only after closing a previous device?)

[jceipek]

I probably won't be able to look into this again until the weekend, but one curious observation is that running MidiMonitor in the background seems to prevent the error from happening, which seems to imply that it is fixable at the RtMidi level?

[radarsat1]

Any luck?

[garyscavone]

This is pretty old and was never verified to be an internal RtMidi problem. I'm tending to close it soon unless someone chimes in.

[evgenyslab]

I probably won't be able to look into this again until the weekend, but one curious observation is that running MidiMonitor in the background seems to prevent the error from happening, which seems to imply that it is fixable at the RtMidi level?

I notice the same behaviour.

[chmedly]

I'm having the same issue with the rtmidi-python wrapper. Seems like an issue in Apple's code. I haven't been able to find any workarounds from my own experimentation but the suggestion here that running midi monitor in the background keeps it from happening is intriguing. I'll give it a try. What's the best way to raise this issue with Apple? In my use case, there are quite a few layers between my code and CoreMidi so I'm not sure how to reduce it for them.

[webpolis]

This is still an issue. My app is running in several Macbooks across the globe and I receive error reports concerning this. It's triggered when it retrieves the list of ports using get_ports()

[keinstein]

One way to find out uninitialized variables is to enable the address sanitizer while compiling and testing the software. Did someone try this with main RtMidi (I'm doing it with my fork regularly, but that's irrelevant, here).

[webpolis]

This happens sporadically; it doesn't make sense and it's not related to rtmidi as far as I know. I've tried using virtual ports on Mac (IAC Driver), and I have to trigger a "Rescan" manually in the Audio / Midi Setup in order to make it work as expected. Somehow, the high revenues of Apple are not well distributed across its developers.

It's funny that MIDI works pretty well in Linux (and by instance, in Windows) but not in a >= $1000 Macboook Pro.

[tschiemer]

Also occuring on macOS Catalina 10.15.4.

It's sort of a CoreMIDI problem and can be easily reproduced by running the code below with option delete (as opposed to no-delete); essentially this is a broken down version of what'd happen when RtMidi objects are created and deleted again.

According to my tests:

After about 7 iterations/seconds (also using different time intervals) of merely creating and disposing a MIDIClient the error occurs (and remains until reopened).

The error requires there not to be any MIDI ports or devices (created in other contexts at least) to exist.

The error does not occur when the created MIDIClient is not disposed of.

The error does also not occur when MIDI Studio of Audio MIDI Setup.app is open.

Although the docs of MIDIClientDispose clearly state that:

It is not essential to call this function; the CoreMIDI framework will automatically dispose all MIDIClients when an application terminates.

The circumstances would suggest that the CoreMIDI Framework (or the MIDI Server for that matter) does not actually update its inner states and actually does not properly dispose of MIDIClients as explicitly requested leading to some sort of internal mess.. - when there is no apparent need to (such as a different process using MIDI services).

possible workarounds (just quickly tested)

• create a separate additional process that opens a MIDIClient (ie instantiates RtMidi-object) and waits when still connected
• edit ~RTMidi to not dispose of MIDIClients.... well, according to the docs disposing is optional, but this might lead to other problems, depending on the setup
• find some other way to force the CoreMIDI Framework, the MIDI Server to update its inner states etc
• refactor RtMidi not to create a MIDIClient for each RtMidi-object but use a singleton instead; which I assume is closer to the assumed use case of the CoreMIDI framework - put/asked differently: how many clients does a process need? (note: I'm not deep into the framework et al here, so I'm merely speculating, no offense intended)

#include <CoreMIDI/CoreMIDI.h>
#include <CoreAudio/HostTime.h>
#include <CoreServices/CoreServices.h>

#include <iostream>
#include <chrono>
#include <thread>
#include <ctime>


int main(int argc, char * argv[]){

  unsigned int interval = 1000;
  bool deleteAfterUsage = true;

  if (argc <= 1){
    std::cout << "Usage: ./coremidi-bug (delete|no-delete)" << std::endl;
    std::cout << "NOTE the bug only occurs if there are no MIDI Ports" << std::endl;
    return EXIT_SUCCESS;
  }

  std::string opt = argv[1];

  if (opt == "delete"){
    deleteAfterUsage = true;
  } else if (opt == "no-delete") {
    deleteAfterUsage = false;
  } else {
    std::cout << "ERROR please specify wether to delete MIDIClientRef object after use" << std::endl;
    return EXIT_FAILURE;
  }

  while(1){

    static unsigned int round = 0;

    std::cout << "Round " << std::to_string(++round) << std::endl;

  
    char clientName[256];
    int len = sprintf(clientName, "myClientName-%d", round);

    MIDIClientRef client;
    CFStringRef name = CFStringCreateWithCString( NULL, clientName, kCFStringEncodingASCII );
    OSStatus result = MIDIClientCreate(name, NULL, NULL, &client );

    if ( result != noErr ) {
        std::cout << "CREATE ERROR " << std::to_string(result) << std::endl;
    } else {
        if (deleteAfterUsage){
          result = MIDIClientDispose(client);
          if (result != noErr ){
            std::cout << "DISPOSE ERROR " << std::to_string(result) << std::endl;
          }

        }
    }

    CFRelease(name);


    std::this_thread::sleep_for(std::chrono::milliseconds(interval));
  }

  return EXIT_SUCCESS;
}

note: the code creates a new name for each instance of the MIDIClient ; reusing the same name makes no difference

edit: untested: https://github.com/tschiemer/rtmidi/tree/coremidi-singleton
Introduced MIDIClient singleton for MidiCoreIn/Out with a public interface to set and dispose through MidiApi.
As the MidiCoreIn/Out are not public that is an easy and somewhat ugly solution.