http://bugs.winehq.org/show_bug.cgi?id=18220
Summary: mWavEdit: midi sysex communication fails Product: Wine Version: 1.1.19 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs@winehq.org ReportedBy: ld0d@kolumbus.fi
Created an attachment (id=20726) --> (http://bugs.winehq.org/attachment.cgi?id=20726) Wine midi call trace log
The SoundTower Microwave Editor 4.0.1 (http://www.soundtower.com/microwave/mw2_files/mw2_page.htm) fails to communicate with the Microwave XT using midi sysex. I attached a log taken with WINEDEBUG=+midi,+winmm,+driver.
The interesting part seems to be: trace:midi:midPrepare (0003, 0x1570c10, 00000040); trace:winmm:MMDRV_Message => MMSYSERR_INVALPARAM
I also traced the code a bit, and it seems that mWavEdit calls midiInPrepareHeader with a buffer of size 70000 (>0x10000) which causes the MMSYSERR_INVALPARAM in midPrepare() (in dlls/winealsa.drv/midi.c). Now, I do not know why the buffer size is limited to 0x10000, but changing the limit to 0x20000 in all the three places in winealsa.drv/midi.c fixes the problem and mWavEdit works perfectly.
Can this be fixed in Wine, or should I contact the authors of the program?
http://bugs.winehq.org/show_bug.cgi?id=18220
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2009-04-26 13:16:23 --- No idea why that limit is there. And it's not just in winealsa but in wineoss too. I think it was copied from there as-is. It might have something to do with 16-bit compatibility - since that function is called by 16-bit functions.
http://bugs.winehq.org/show_bug.cgi?id=18220
--- Comment #2 from Austin English austinenglish@gmail.com 2009-10-29 15:26:37 --- Is this still an issue in current (1.1.32 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=18220
--- Comment #3 from Lauri Koponen ld0d@kolumbus.fi 2009-10-30 13:49:17 --- Yes, it's still an issue in 1.1.32. The buffer length is still limited to 0x10000 bytes in winealsa.drv.
http://bugs.winehq.org/show_bug.cgi?id=18220
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2010-01-28 04:00:52 ---
No idea why that limit is there.
Perhaps http://msdn.microsoft.com/en-us/library/dd798477%28VS.85%29.aspx "A stream buffer cannot be larger than 64K" => INVALPARAM (which is about midiOutPrepareHeader, while midiInPrepareHeaders says nothing like this).
Now somebody needs to do additional testing to determine when/how midiIn/OutPrepareHeader may return INVALPARAM for buffers >64K and when not, i.e. how to detect a stream buffer. I can add some tests to my emerging MIDI testsuite.
BTW, for comparison I'd like to see a +midi,+winmm,+driver application log with Lauri's hack that permits a larger buffer size.
http://bugs.winehq.org/show_bug.cgi?id=18220
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2010-02-03 09:55:14 --- I wrote the tests and commit a758c6a981b1f4d3653f9cf44f6d136f2fc0e6b3 This should solve this bug as per comment #0. Lauri or somebody with admin rights, please mark as solved.
http://bugs.winehq.org/show_bug.cgi?id=18220
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com 2010-02-03 09:58:16 --- (In reply to comment #5)
I wrote the tests and commit a758c6a981b1f4d3653f9cf44f6d136f2fc0e6b3 This should solve this bug as per comment #0. Lauri or somebody with admin rights, please mark as solved.
Marking fixed. Thanks, Jörg.
Lauri, feel free to reopen if this is still a problem.
http://bugs.winehq.org/show_bug.cgi?id=18220
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2010-02-05 11:38:52 --- Closing bugs fixed in 1.1.38.