On Thu, Dec 09, 2021 at 09:31:12PM -0700, Kolten Pearson wrote:
I have been working on reverse engineering the sysex commands to control an Arturia MiniLab mkII controller, and have run into an issue where the rawmidi driver is dropping some of the commands. Here is a snippet of my code that illustrates the problem
snd_rawmidi_t* midi_input; snd_rawmidi_t* midi_output;
void midi_init() { int ret = snd_rawmidi_open(&midi_input, &midi_output, "hw:3,0,0", SND_RAWMIDI_NONBLOCK);
You're opening in non-blocking mode here, which may affect the behaviour later...
int count = snd_rawmidi_write(midi_output, raw_command,sizeof(raw_command)); assert(count == sizeof(raw_command) && "bad write");
Are you definitely compiling with these asserts enabled? Have you considered:
if (count != sizeof(raw_command)) warnx("bad write");
//SDL_Delay(1); int ret = snd_rawmidi_drain(midi_output); assert(ret == 0 && "could not drain");}
When this code is run, the minilab will only respond to a nondeterministic number of calls to the midi_set function and ignore the rest. However if the SDL_Delay(1) line is uncommented, it will work correctly every time (This function call causes the process to sleep for at least 1 millisecond).
I feel like the call to snd_rawmidi_drain should make the SDL_Delay call unnecessary, but that is not the case. Is there something I am not understanding about how the api works?
How is the Arturia device connected? Is it USB?
I wonder if it is the device that is dropping the data. Normally USB MIDI devices will NAK transfers if they are unable to process data but maybe that is not happening here.
You may be able to use usbmon and Wireshark to capture the USB traffic to the device and confirm whether the data is being sent over the bus or if it is being lost in the rawmidi layer somehow.