winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

Johannes Kroll wrote:

  9.532:003a:trace:midi:modLongData dwBufferLength=88 !
f0 42 41 00 01 11 01 7f 4b 40 7a 01 7f 02 7f 7f .BA.....K at z.....
7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q. at ...........
00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 7f 7f 7f ....... at ..|.....
7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f ................
7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f ................
7f 7f 01 7f f7 00 00 00                         ........

Could you please log dwBytesRecorded next to
     TRACE("dwBufferLength=%u !\n", lpMidiHdr->dwBufferLength);

I once proved that dwBytesRecorded is what gets used with midiSTREAMout

>So there is an F7 there... Maybe the app expects that the driver scans
>through the buffer for the F7 and doesn't send the following bytes...

Net.wisdom is that modLongData need be scanned for coalesced regular status
messages, e.g. some people use it to play chords, arguing that one LongMsg is
faster than 3 consecutive midiOutShortMsg.  That's a patch yet to be written.

However, I wouldn't know what to do with the three 00 bytes. That's not MIDI!

Also, I'm wondering what ALSA does with that packet. Do the bytes as shown really
make their way over the serial port?  (Perhaps you could use some virtual MIDI device
to dump what ALSA processes internally?)

Do you have a working wineOSS? WineOSS simply dumps the bytes one by one and does
not require us to tell it what a sysex might be.  I already tested that disguising a chord
as an ALSA SysEx within midiOutLongMsg doesn't work (at least with a SW synth).

Thank you,
 Jörg Höhle