Core Midi sending wrong usb packets on MacOS 13.3.1

Question

davidgiga1993 OP

Created May ’23

Replies 6

Boosts 2

Views 1.2k

Participants 2

I've got an app that communicates with midi devices, this app worked fine for years, however since MacOS 13.3 and iOS 16 users complained about strange behaviors.

After days of debugging I found out that the USB Midi Packets sent are sometimes invalid (wrapped in sysex headers).

Here is the extract used to sent a single midi message

  UInt8 mBuffers[100];
  MIDIPacketList* packetList = (MIDIPacketList*) mBuffers;
  MIDIPacket* packet = MIDIPacketListInit(packetList);
    MIDIPacketListAdd(packetList, sizeof(mBuffers), packet, 0, messageLength, (Byte *) messageData);
    
  printf("Sending %i bytes ", messageLength);
  for (int i = 0; i &lt; messageLength; i++)
  {
      if (i > 0) printf(":");
      printf("%02X", (Byte)messageData[i]);
  }
  printf("\n");
  fflush(stdout);
  
  status = MIDISend(outputPortReference, endPointReference, packetList);

Here is the output of the program when the issues occurs:

Sending 3 bytes E0:00:00
Sending 3 bytes D0:00:00
Sending 3 bytes E1:00:00
Sending 3 bytes D0:1B:00
Sending 3 bytes E2:00:00
Sending 3 bytes D0:2B:00
Sending 3 bytes E3:00:00
Sending 3 bytes D0:3B:00
Sending 3 bytes D0:4A:00
Sending 3 bytes D0:5A:00
Sending 3 bytes D0:6A:00
Sending 3 bytes D0:79:00

The data rate is relatively high (~100ms per message)

However when looking at the usb stack, the following data gets sent:

0e e0 00 00 -> Match
0d d0 00 00 -> Match
04 00 e1 00 -> WRONG  - wrapped in Sysex
04 00 d0 1b -> WRONG  - wrapped in Sysex
0f 00 00 00 -> Padding
0e e2 00 00 -> Match
0d d0 2b 00 -> Match
04 00 e3 00 -> WRONG  - wrapped in Sysex
04 00 d0 3b -> WRONG  - wrapped in Sysex
04 00 d0 4a -> WRONG  - wrapped in Sysex
0f 00 00 00 -> Padding
0d d0 5a 00 -> Match
0f 00 00 00 -> Padding
0d d0 6a 00 -> Match
04 00 d0 79 -> WRONG  - wrapped in Sysex
0f 00 00 00 -> Padding

I can't explain anymore why this is happening and looking for some advice. Since I can't debug on that level on iOS I can only guess that the root cause is the same.

Does anyone know about such an issue? Any ideas how to further debug?

Boost

Answer 1

MobileTen OP

May ’23

Then you will most likely need to update your applications if Apple has addressed issues in the API.

0

Answer 2

davidgiga1993 OP

May ’23

What do you mean? The api is still available and the behavior shouldn't change between MacOS versions. Especially since it produces invalid packets.

0

Answer 3

MobileTen OP

May ’23

Creating a feedback ticket with a sample app and the observations above might be best.

0

Answer 4

MobileTen OP

May ’23

Creating a feedback ticket with a sample app and the observations above might be best.

0

Answer 5

davidgiga1993 OP

May ’23

For anyone interested: The behavior on MacOS and iOS is slightly different, yet both cases are annoying. I managed to resolve the MacOS issue by using the MIDI2.0 api, and sending sysex using the dedicated sendSysex method. Important: Block sending any other requests until the sysex callback has been received.

On iOS however, midi seems generally broken, regardless of which API is used:

When sysex is sent (using sendsysex) all midi messages after that for the next 500ms are simply dropped and not delivered.
Sending sysex directly with a MIDI 2.0 UMP packet doesn't do anything at all.

As far as I can tell there is no workaround to quickly send sysex and note/cc events, which makes my entire platform broken in the apple ecosystem.

0

Answer 6

davidgiga1993 OP

May ’23

Submitted ticket with more details: https://feedbackassistant.apple.com/feedback/12194198

0