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

[Johannes Kroll]

On Wed, 13 Feb 2013 09:29:19 +0100
<Joerg-Cyril.Hoehle at t-systems.com> wrote:

> 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

I did. It is in the log line that you deleted. Immediately after the
hex dump...

    TRACE("dwBufferLength=%u !\n", lpMidiHdr->dwBufferLength);
    //~ TRACE("                 %02X %02X %02X ... %02X %02X %02X\n",
	  //~ lpData[0], lpData[1], lpData[2], lpData[lpMidiHdr->dwBufferLength-3],
	  //~ lpData[lpMidiHdr->dwBufferLength-2], lpData[lpMidiHdr->dwBufferLength-1]);
    { unsigned long dwToGo;
        #define dprintf(x...) fprintf(stderr, x)
             for (dwToGo = 0; dwToGo < lpMidiHdr->dwBufferLength; dwToGo += 16) {
                 DWORD       i;
                 BYTE        ch;
 
                 for (i = 0; i < min(16, lpMidiHdr->dwBufferLength - dwToGo); i++)
                     dprintf("%02x ", lpData[dwToGo + i]);
                 for (; i < 16; i++)
                     dprintf("   ");
                 for (i = 0; i < min(16, lpMidiHdr->dwBufferLength - dwToGo); i++) {
                     ch = lpData[dwToGo + i];
                     dprintf("%c", (ch >= 0x20 && ch < 0x7F) ? ch : '.');
                 }
                 dprintf("\n");
             }
             TRACE("dwBytesRecorded=%d\n", lpMidiHdr->dwBytesRecorded);
    }



> >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!

No. Maybe dwBytesRecorded *should* be the length of the data. But it
isn't, it's always zero. Yes, really, I checked in several runs.

> 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?)

If I figure out a way to do that I'll let you know...

> 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).

No, I don't have wineOSS. Does it require a proper OSSv4? Or would it
work with ALSA OSS emulation? I don't have 'real' OSS.