Truncate MIDI SysEx messages after termination byte

Christian Costa titan.costa at
Fri Jan 18 13:05:29 CST 2013

Le 18/01/2013 17:16, Joerg-Cyril.Hoehle at a écrit :
> Hi,
> Although I wouldn't mind inclusion of Christian's F0/F7 patch in upcoming Wine
> (barring decent formatting), I beg and urge Johannes Kroll to nevertheless submit
> a bug report about F0/F7 handling *and* provide a log of all SysEx messages sent
> submitted by the app to Wine.
> There's code to dump the data contents in another library that he could copy
> to winealsa to produce the SysEx dump:
> What becomes clear from below documents is that at least our mciseq .mid file parser
> does not handle SysEx continuations aka. divided SysEx,
> nor encapsulated SysEx aka. encapsulated events at all.
> You could argue that .mid file parsing has no influence on winealsa.
> However, as midiOutLongMsg and midiOutShortMsg are the only low-level API
> calls available, the question is whether native is able to send such partial
> SysEx to external HW devices.  Obviously, automatically padding with F0/F7
> (which winealsa would like to do and wineoss does) prevents that.
> Should one expect the native low-level drivers to split large SysEx and insert
> pauses during transmission, or should the apps be able to split and send themselves?
> The existence of SysEx continuations in MIDI files causes me to believe that the
> same splitting should be possible on the output side, under control of the app.
> It's also unclear how the backends would react to missing F0/F7 delimiters.
> ALSA says: "the sysex data must contain the start byte 0xf0 and the end byte 0xf7."
> Regards,
> 	Jörg Höhle
One thing we can do it is to check what native winmm really does by 
writing a fake low level driver.
If we can register it dynamically like ICInstall from msvideo we can do 
all the checks we want in the tests.


More information about the wine-devel mailing list