[Bug 33126] divided SysEx and coalesced midiOutLongMsg

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=33126

Daniel P. <[e-mail]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #3 from Daniel P. <[e-mail]> ---
Still present in wine-11.17 (winealsa.drv).

Minimal reproduction, using only the ALSA "Midi Through" loopback, so no
hardware and no second application are involved.

midilong.c:

    /* winegcc midilong.c -lwinmm -o midilong
     *
     * Sends one Control Change (BF 54 55) to the ALSA "Midi Through" loopback
     * via midiOutLongMsg. This is NOT SysEx: there is no F0/F7, and 0xBF is a
     * status byte.
     */
    #include <stdio.h>
    #include <string.h>
    #include <windows.h>
    #include <mmsystem.h>

    int main(void)
    {
        HMIDIOUT out;
        MIDIHDR hdr = {0};
        char cc[] = {0xBF, 0x54, 0x55};
        MIDIOUTCAPSA caps;
        UINT i, dev = (UINT)-1;

        for (i = 0; i < midiOutGetNumDevs(); i++)
            if (midiOutGetDevCapsA(i, &caps, sizeof(caps)) == MMSYSERR_NOERROR
&&
                strstr(caps.szPname, "Midi Through")) { dev = i; break; }

        if (dev == (UINT)-1) { printf("no Midi Through device\n"); return 1; }
        printf("sending to %u: %s\n", dev, caps.szPname);

        if (midiOutOpen(&out, dev, 0, 0, CALLBACK_NULL) != MMSYSERR_NOERROR)
return 1;

        hdr.lpData = cc;
        hdr.dwBufferLength = sizeof(cc);
        midiOutPrepareHeader(out, &hdr, sizeof(hdr));
        midiOutLongMsg(out, &hdr, sizeof(hdr));
        Sleep(500);
        midiOutUnprepareHeader(out, &hdr, sizeof(hdr));
        midiOutClose(out);
        return 0;
    }

Steps:

    $ winegcc midilong.c -lwinmm -o midilong
    $ aseqdump -p "Midi Through:0" &
    $ ./midilong

Expected, as a Control Change:

     14:0   Control change         15, controller 84, value 85

Actual:

     14:0   System exclusive           F0 BF 54 55 F7

The buffer is wrapped in F0/F7 and emitted as a SysEx event. That is not
valid MIDI -- 0xBF has its high bit set and cannot appear in a SysEx payload
-- so a receiving device discards it.

As a control, sending the same three bytes to the same port from ALSA, in the
same aseqdump session, arrives correctly:

    $ aseqsend -p "Midi Through:0" "BF 54 55"

     14:0   System exclusive           F0 BF 54 55 F7            <- midilong
     14:0   Control change         15, controller 84, value 85   <- aseqsend

As noted in comment #0, midiOutLongMsg accepts coalesced status messages and
not only SysEx, so the buffer should be decomposed rather than assumed to be
SysEx and framed.

This looks like the same mechanism as bug 39048, fixed in 2.2
(53454ce9359f4ec485aa9411a0e9b14e3d1ed0fa) by not using
snd_seq_ev_set_sysex() for realtime messages. That fix covered the realtime
path only; midiOutLongMsg still frames unconditionally.

Found via a real application: I was trying use the NUX Audio editor for my
guitar multi-fx. It sends well-formed SysEx for queries, which works, and
Control
Changes via midiOutLongMsg for parameter edits, which the device rejects. The
application therefore connects and displays correct state while every edit is
silently ignored.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.