On Wed, 13 Feb 2013 09:29:19 +0100 Joerg-Cyril.Hoehle@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@z..... 7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q.@........... 00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 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 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.