Truncate MIDI SysEx messages after termination byte
titan.costa at gmail.com
Fri Jan 18 13:06:44 CST 2013
Le 18/01/2013 17:16, Joerg-Cyril.Hoehle at t-systems.com a écrit :
> 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."
> 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.
Maybe winmm does more things that we think.
More information about the wine-devel