[Bug 33126] New: divided SysEx and coalesced midiOutLongMsg
http://bugs.winehq.org/show_bug.cgi?id=33126 Bug #: 33126 Summary: divided SysEx and coalesced midiOutLongMsg Product: Wine Version: 1.5.25 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: winealsa.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net Classification: Unclassified Johannes Kroll reported in wine-patches that the KORG Kontrol Editor software hung after sending an ill-formed SysEx via winealsa's midiOutLongMsg. http://www.winehq.org/pipermail/wine-patches/2013-January/121335.html The MIDIHDR data is F0 ... F7 00 00 00 (125 bytes). http://www.winehq.org/pipermail/wine-devel/2013-February/098852.html He observed that no hang occurs when skipping the trailing 3 zero bytes. F7 is the "End Of SysEx" (EOX) marker. It is still unclear what happens. MIDI HW is expected to skip over bogus bytes, thus the zero bytes should cause no harm. OTOH, ALSA might be getting into trouble processing ill-formed messages, and we don't know if or how many bytes ALSA actually sent out through the serial port. In any case, midiOutLongMsg handling in Wine needs fixes. - winealsa should extract the F0...F7 part and send that as a SysEx. - More generally, midiOutLong is known to accept not only SysEx packets, but also coalesced status messages. Some MIDI authors prefer to send e.g. chords via one LongMsg rather than successive calls to midiOutShortMsg, arguing that it's faster. Hence all Wine MIDI drivers need to decompose midiOutLongMsg into packets consisting of status message, regular SysEx ... and possibly junk. - All APIs (MS, ALSA, OSS, CA) acknowledge the existence of divided SysEx. As a result, framing SysEx with F0 ... F7 is entirely under application control. The current winealsa framing code is simply wrong. - winecoreaudio always declared 3 bytes for short messages, even program change. I have written a sequence of patches to fix all of this. The only thing that is unclear is how to encapsulate garbage data like the above 3 zero bytes or real time messages with ALSA. What ALSA API function and what ALSA message type to use? Heck, I'm not even sure winealsa.drv/midi.c:modData is ok to send a 2-byte MTC quarter frame via snd_seq_ev_set_sysex instead of using a primitive that sets the type SND_SEQ_EVENT_CLOCK/TICK. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=33126 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=33126 --- Comment #1 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2013-03-05 04:51:22 CST --- Created attachment 43814 --> http://bugs.winehq.org/attachment.cgi?id=43814 MIDI SysEx patch set awaiting Johannes' confirmation -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
https://bugs.winehq.org/show_bug.cgi?id=33126 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #2 from Fabian Maurer <dark.shadow4(a)web.de> --- Is this still an issue? Is the originally tested software even still available? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=33126 Daniel P. <purkhusid@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |purkhusid@gmail.com --- Comment #3 from Daniel P. <purkhusid@gmail.com> --- 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.
http://bugs.winehq.org/show_bug.cgi?id=33126 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase -- 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.
participants (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla
-
WineHQ Bugzilla