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.
