http://bugs.winehq.org/show_bug.cgi?id=21643
Summary: No background music in Pikachu Volleyball 1.0 Product: Wine Version: 1.1.38 Platform: x86-64 URL: http://andrew.jaww.net/blog/article/54/pikachu-volleyb all OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: RandomAccountName@mail.com
Starting in 1.1.38, the background music in version 1.0 of this game no longer plays. The result from my regression test is:
8894da4a6e3d6a0f5d15d5770ef8102162f6facc is first bad commit commit 8894da4a6e3d6a0f5d15d5770ef8102162f6facc Author: Jörg Höhle hoehle@users.sourceforge.net Date: Wed Jan 27 17:18:14 2010 +0100
midimap: Refuse to open when asked for yet unimplemented callbacks.
:040000 040000 2870e6974bdad551f707817652738f9b1fb172d7 5b5264d9c7c72677f11a762b586f472cae627efe M dlls
Reverting this patch fixes the problem.
http://bugs.winehq.org/show_bug.cgi?id=21643
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression CC| |hoehle@users.sourceforge.ne | |t
http://bugs.winehq.org/show_bug.cgi?id=21643
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winmm&mci
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com 2010-02-08 10:39:35 --- Please attach terminal output.
http://bugs.winehq.org/show_bug.cgi?id=21643
--- Comment #2 from A Wine user RandomAccountName@mail.com 2010-02-08 10:41:50 --- Created an attachment (id=26130) --> (http://bugs.winehq.org/attachment.cgi?id=26130) Terminal output in 1.1.38
Sorry, that should be Jörg Höhle.
Here is terminal output from 1.1.38.
http://bugs.winehq.org/show_bug.cgi?id=21643
--- Comment #3 from Jörg Höhle hoehle@users.sourceforge.net 2010-02-08 10:54:28 --- fixme:msacm:modOpen NIY callback flags 00030000 This is crazy. It shows that the app asked for a function callback that was not invoked in the past, yet the app worked?!? Could you please try my HACK from bug #9220, comment #17? http://bugs.winehq.org/attachment.cgi?id=25917 It's mere curiosity in order to know whether BGM works better than <1.1.38 with this hack (e.g. start/stop/abort BGM, no hangs)?
In any case, the only proper solution is to implement the NIY callbacks.
http://bugs.winehq.org/show_bug.cgi?id=21643
--- Comment #4 from A Wine user RandomAccountName@mail.com 2010-02-09 05:01:17 --- (In reply to comment #3)
It's mere curiosity in order to know whether BGM works better than <1.1.38 with this hack (e.g. start/stop/abort BGM, no hangs)?
With your hack applied to current git, everything works perfectly as far as I can tell. No problems with the music playing, stopping, or resetting/exiting the game while the music is playing. No hangs or crashes.
It works the same as in Windows or in 1.1.38 with commit 8894da4a6e3d6a0f5d15d5770ef8102162f6facc reverted. It works better than <1.1.38 due to earlier versions being affected by another bug (bug 21580).
http://bugs.winehq.org/show_bug.cgi?id=21643
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2010-02-09 06:09:28 ---
It works better than <1.1.38
Good to hear. Regarding your bug #21580, I assume one of the MIDI improvements between 1.1.37 and 1.1.38 made the loop work, but the "refuse to open" patch plays it safe, showing a useful fixme message (perhaps err would have been better) instead of allowing Wine to hang as in bug #9220 (or hang partly waiting to loop the MIDI song).
Its drawback is it silences all apps that access the MIDI mapper with callback flags and offer no configuration setting for using another MIDI device (e.g. device #0).
To hear the music, you'll have to use my "redirect MIDI mapper to device #0" hack until I -- or somebody else -- implements notification for the MIDI mapper. Thank you for your bug report. BTW, are those "ooch" and "Unknown MEVT" fixme still present in 1.1.38 with the hack applied?
Admins, please mark this as "confirmed".
http://bugs.winehq.org/show_bug.cgi?id=21643
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #6 from Andrew Nguyen arethusa26@gmail.com 2010-02-09 06:12:15 --- I'm confirming the bug as per comment #5.
http://bugs.winehq.org/show_bug.cgi?id=21643
--- Comment #7 from A Wine user RandomAccountName@mail.com 2010-02-09 06:31:52 --- (In reply to comment #5)
BTW, are those "ooch" and "Unknown MEVT" fixme still present in 1.1.38 with the hack applied?
The unknown MEVT fixme is still present, but all the ooch lines are gone.
http://bugs.winehq.org/show_bug.cgi?id=21643
--- Comment #8 from Jörg Höhle hoehle@users.sourceforge.net 2010-02-11 18:25:42 --- Issue fixed by commit a8b80787047a87b62355b8524d68979ae19a2adb Please mark as resolved, so it will become closed with the next release.
all the ooch lines are gone.
Actually not surprising, only the mapper reports that.
2 observations: winmm:Adding stream [dwBufferLength=4096/4092 size=64] winmm:Adding stream [dwBufferLength=4096/1296 size=64] It looks like this program mixes dwBufferLength and dwBufferRecorded -- unless MS changed the structures some time! The sizes 4092 and 1296 look like the actual buffer sizes, and it seems the ooch and MEVT would be avoided if these were the true limits. Instead, Wine scans the buffer until 4096 and barfs on garbage.
Scanning the internet, it looks like the sizeof(MIDIHDR) check in midiOutPrepare in Wine is inappropriate. This program is not affected, but there's a lot of VB sample code that does not know the dwOffset and dwReserved[8] slots, hence supplies a smaller size. Likewise, some other code (.NET, Perl, Python) and MSDN lists dwReserved[4]. Wine would not allow to Prepare those samples. There must be a lot of MIDI apps mute in Wine out there, let's go find them. In the meantime, more tests are needed.
http://bugs.winehq.org/show_bug.cgi?id=21643
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #9 from A Wine user RandomAccountName@mail.com 2010-02-12 01:26:22 --- Marking fixed. Thanks, that was fast!
I have some other programs that use MIDI which I either haven't tested in Wine, or they had MIDI-related issues last time I checked and I never reported them. I guess I'll (re)test them in git and report any issues I find when I get the chance.
http://bugs.winehq.org/show_bug.cgi?id=21643
--- Comment #10 from Jörg Höhle hoehle@users.sourceforge.net 2010-02-15 10:14:17 --- winmm:Adding stream [dwBufferLength=4096/4092 size=64] Wine is wrong: tests with MIDIHDR show that dwBytesRecorded is the limit, not BufferLength. Obeying this limit should make the "ooch" and "Unknown" disappear, Expect a patch RSN.
Now who's gonna write similar tests for WAVEHDR?
I'll (re)test them in git
It's always good to retest in Wine -- and perform RegressionTesting. So many things change.
http://bugs.winehq.org/show_bug.cgi?id=21643
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2010-02-19 12:32:33 --- Closing bugs fixed in 1.1.39.
http://bugs.winehq.org/show_bug.cgi?id=21643
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a8b80787047a87b62355b8524d6 | |8979ae19a2adb Regression SHA1| |8894da4a6e3d6a0f5d15d5770ef | |8102162f6facc
-
wine-bugs＠winehq.org