http://bugs.winehq.org/show_bug.cgi?id=28982
Bug #: 28982 Summary: Application crashes on DSound playback Product: Wine Version: 1.3.31 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dsound AssignedTo: wine-bugs@winehq.org ReportedBy: mailRoxas@gmail.com Classification: Unclassified
Created attachment 37279 --> http://bugs.winehq.org/attachment.cgi?id=37279 WINEDEBUG log
Zero no Kiseki crashes when it tries to play 44100Hz Stereo WAVE music. It does not crash when it's playing 22050Hz Mono WAVE sound effect.
The crash comes from DSound wrapper .dll called sound3d.dll that basically seems to just load and play sound/music accordingly.
Attached is a WINEDEBUG=+tid,+mmdevapi,+winmm,+midi,+dsound,+dmusic,+mci,+oss,+alsa,+coreaudio output of the application.
http://bugs.winehq.org/show_bug.cgi?id=28982
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=28982
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-dsound |-unknown Summary|Application crashes on |Application Zero no Kiseki |DSound playback |crashes when it tries to | |play 44100Hz Stereo WAVE | |music
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #1 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-05 07:13:02 CDT --- Created attachment 37317 --> http://bugs.winehq.org/attachment.cgi?id=37317 WINDEBUG=+seh,+tid output
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #2 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-05 10:41:58 CDT --- Taking out the return on line 872 in mmio.c return send_message(wm->ioProc, &wm->info, MMIOM_SEEK, lOffset, iOrigin, FALSE);
(Probably because the return value of send_message is not compatible with mmio_seek return)
Makes the sound effects work and they are no more distorted. Application does not crash anymore either. However, music still does not play. But it's already much better. I'll keep investigating.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #3 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-05 11:21:16 CDT --- When swapping sound effect 22050Hz mono file with 44100HZ Stereo WAVE file, the music works like expected when sound effect is playing.
So, the the game must have secondary code path for playing music, or it might be muted for some reason.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #4 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-06 07:23:19 CST --- Ok, it seems like the music is playing with the "fix" above, but it just ends the loop too quickly and hence starting the music again.
Since some BGMs have silent start it feels like they are not playing at all, but for example town music which starts instantly loops the first seconds.
I'll check what values need to be truly returned.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #5 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-06 11:32:00 CST --- Created attachment 37341 --> http://bugs.winehq.org/attachment.cgi?id=37341 Add extra handling for unbuffered MMIO handles
Ok, here is a patch that solves all the problems. It fixes crashing, stuttering sound effect, and background music.
Normally the background music just stuttered when it finished, so I guess mmioRead returns the END of file and seeks to beginning of the file on unbuffered mmio.
Maybe it's just bad coding on the application's part, but yeah this works and I dint notice any bugs. It might break other applications thought? Needs more testing.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #6 from Andrew Eikum aeikum@codeweavers.com 2011-11-07 09:56:19 CST --- (In reply to comment #5)
Created attachment 37341 [details] Add extra handling for unbuffered MMIO handles
Ok, here is a patch that solves all the problems. It fixes crashing, stuttering sound effect, and background music.
Maybe it's just bad coding on the application's part, but yeah this works and I dint notice any bugs. It might break other applications thought? Needs more testing.
The patch looks plausible, and passes all of the existing MMIO tests for me. Could you try writing some tests in <dlls/winmm/tests/mmio.c> for the behavior changes that you're adding? I also noticed that there are some #ifdef-ed out blocks in that file with "remove once passes under Wine" comments; would you expect your patch to fix any of these?
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #7 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-07 11:56:38 CST --- I'll get back home next week. I'll check the tests if it fixes any of the #ifdeffed parts and write new ones if needed then. I din't notice any breakage on other applications I used.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #8 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-12 14:06:26 CST --- With the patch, the ifdeffed: ok(mmio.lBufOffset == 0, "expected 0, got %d\n", mmio.lBufOffset); ok(mmio.lDiskOffset == 0, "expected 0, got %d\n", mmio.lDiskOffset);
Seems to pass correctly, however it does not affect the SEEK_CUR tests. There should be new test case written for direct mmioread for unbuffered file, however there are currently no mmioread tests there.
http://bugs.winehq.org/show_bug.cgi?id=28982
Jari Vetoniemi mailRoxas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37341|0 |1 is obsolete| |
--- Comment #9 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-26 06:06:13 CST --- Created attachment 37636 --> http://bugs.winehq.org/attachment.cgi?id=37636 Add extra handling for unbuffered MMIO handles
Clean the patch a bit, and add more information about the issue. Also sent to a mailing list, however don't know if I did the procedure correctly.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #10 from Andrew Eikum aeikum@codeweavers.com 2011-11-28 07:45:24 CST --- Hi Jari,
Yes, you sent the patch correctly. However, it was rejected by Alexandre as "Needs tests" on http://source.winehq.org/patches/ (it has since fallen off of that list). I'm not familiar with the MMIO procedures in winmm, so I'm afraid I can't be much help writing tests right now. Is this something you're able to work on?
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #11 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-28 08:49:39 CST --- Ah, that list is really handy :)
I'm not sure what kind of tests I should write to it, but I see what I can do. Something that triggers the bad behavior with unpatched wine in /tests would do I guess?
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #12 from Andrew Eikum aeikum@codeweavers.com 2011-11-28 08:54:10 CST --- Yep, that's exactly right. Something that fails before your patch and succeeds afterwards. Obviously your tests must also pass on Windows. You can use the testbot at https://testbot.winehq.org/ to test your patch on several versions of Windows running in VMs.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #13 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-28 09:02:37 CST --- That sounds good. I'll try to write them this weekend, maybe earlier and try again.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #14 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-30 07:26:35 CST --- Created attachment 37706 --> http://bugs.winehq.org/attachment.cgi?id=37706 Add tests for mmioRead
Well, I did some tests bit earlier than expected. I'll add it here as attachment, so you can check if it looks good.
Since the bug only appears on direct read to file (unbuffered handle, or whatever you want to call it) I added wname variable there which can be pointed to .wav file in example.
Tested without patch and it fails, with patch it succeeds. MMIO's handled in memory succeed with and without.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #15 from Andrew Eikum aeikum@codeweavers.com 2011-11-30 10:49:13 CST --- (In reply to comment #14)
Created attachment 37706 [details] Add tests for mmioRead
Well, I did some tests bit earlier than expected. I'll add it here as attachment, so you can check if it looks good.
Since the bug only appears on direct read to file (unbuffered handle, or whatever you want to call it) I added wname variable there which can be pointed to .wav file in example.
Tested without patch and it fails, with patch it succeeds. MMIO's handled in memory succeed with and without.
This needs some more work, I think. I have a WAV file which returns 4 from the last mmioRead(..., 8) on Windows 7. That also makes sense to me, that mmioRead() would return the most it could read before EOF.
Can you describe exactly what the program is doing that leads to the crash?
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #16 from Jari Vetoniemi mailRoxas@gmail.com 2011-11-30 11:02:07 CST --- It makes sense for it to read the most it could read before EOF yes, but this for some reason causes the application to loop the last bit of the background music again before starting it over.
That mmioRead part is only for the music loop issue, the actual crash fix was in mmioSeek which dint set the offset variable before returning.
Which then again makes me thing that the test I did dint not crash on seeking with unpatched wine, so there must be something else the application is doing as well. Guess I need to dig in more and try do it more prober way.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #17 from Jari Vetoniemi mailRoxas@gmail.com 2011-12-01 13:55:42 CST --- Ok, I made better patch that returns the same results as with your Windows, and came to conclusion that the music looping issue at end might be issue on somewhere else, I'll try to find more about that as well.
I'll post the proper fixes when I can reproduce a test that causes wine to crash on mmioSeek :)
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #18 from Jari Vetoniemi mailRoxas@gmail.com 2011-12-01 15:59:52 CST --- Actually, it seems like the crash has been fixed in wine already it seems. Better way than mine at least. The reason for it seemed to be access to uninitialized variable.
There is still the BGM looping issue however, but the solution for it isn't in mmioRead. That seems to be just a hack, I'm still looking the real cause for this. It might not be in winmm at all for example (maybe alsadrv?).
Anyways, this bug can be marked as fixed now.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #19 from Jari Vetoniemi mailRoxas@gmail.com 2011-12-01 16:49:42 CST --- Bleh, nevermind the earlier comment. Tested the application with system's wine. So yeah, keep the bug open :)
http://bugs.winehq.org/show_bug.cgi?id=28982
Jari Vetoniemi mailRoxas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37636|0 |1 is obsolete| |
--- Comment #20 from Jari Vetoniemi mailRoxas@gmail.com 2011-12-06 14:04:01 CST --- Created attachment 37834 --> http://bugs.winehq.org/attachment.cgi?id=37834 New patch
Ok, this patch should be bit better.
But anyways, I'm going to clear up things here a bit. First of all, I have no idea why setting lBufOffset on MMIOM_SEEK causes the program not crash. I've reversed the DLL that handles the BGM music in game, but did not found anything useful, and wine output isn't particular helpful either.
Second, to make the BGM loop, the file must be seek back when file read function returns EOF. There is still that "looping" issue, but I'm pretty sure it's issue somewhere else, maybe not even in wine.
The earlier test I wrote, should at least success with this on both windows and linux, but yeah. More work is still needed, like finding what is the real reason for the crash and how to write test for that.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #21 from Jari Vetoniemi mailRoxas@gmail.com 2012-03-11 06:47:26 CDT --- With latest wine git, game does not crash any more. However audio still doesn't "play", and some sounds are distorted.
About the audio not playing, I think it's actually playing, but repeating after ridiculous short time of playing, since the game slows down a lot (and on some areas short clips of the BGM can be heard.).
The patch in this bug still fixes all the audio issues.
http://bugs.winehq.org/show_bug.cgi?id=28982
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winmm&mci
http://bugs.winehq.org/show_bug.cgi?id=28982
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #22 from Jerome Leclanche adys.wh@gmail.com 2012-04-19 22:24:36 CDT --- Updates on this bug and patch?
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #23 from Jari Vetoniemi mailRoxas@gmail.com 2012-04-20 13:14:53 CDT --- It's again broken on latest git again, doesn't even start. Patch still works. Haven't had time investigating where the real issue is and provide a prober patch since I'm busy with life ATM. However the current workaround works pretty nicely for the game if you just want to play it.
http://bugs.winehq.org/show_bug.cgi?id=28982
Michael Mc Donnell michael@mcdonnell.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@mcdonnell.dk
http://bugs.winehq.org/show_bug.cgi?id=28982
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #24 from Andrew Eikum aeikum@codeweavers.com 2012-11-14 09:01:57 CST --- Akihiro Sagawa is doing some work on this area of Wine. You might be interested in following his patches and seeing if they fix things here. They should be in the next release of Wine.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #25 from Jari Vetoniemi mailRoxas@gmail.com 2012-11-14 11:44:21 CST --- Thank you for informing. I'll follow on the issue and report when it's fixed here.
http://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #26 from Jari Vetoniemi mailRoxas@gmail.com 2012-11-19 17:24:37 CST --- Just popping in and confirming that with vanilla wine compiled from git (wine-1.5.17-189-g78b08cd) This issue still reminds, and game crashes on startup.
I'll follow up on Akihiro Sagawa contributions and post here if situation changes. If I can allocate some time, maybe I can help with making proper patch for this issue as well.
https://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #27 from Austin English austinenglish@gmail.com --- Is this still an issue in current (1.7.35 or newer) wine? If so, please attach terminal output.
https://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #28 from Jari Vetoniemi mailRoxas@gmail.com --- I'll test today.
https://bugs.winehq.org/show_bug.cgi?id=28982
--- Comment #29 from Jari Vetoniemi mailRoxas@gmail.com --- Game works, and sound/music plays. The background music does not loop properly however, instead keeps repeating the last 2-3 seconds of the end of the song.
The log seemed quite quiet. Should I post one with some WINEDEBUG options enabled?
https://bugs.winehq.org/show_bug.cgi?id=28982
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #30 from super_man@post.com --- (In reply to Jari Vetoniemi from comment #29)
Game works, and sound/music plays. The background music does not loop properly however, instead keeps repeating the last 2-3 seconds of the end of the song.
The log seemed quite quiet. Should I post one with some WINEDEBUG options enabled?
So it's not crashing anymore? Then this is fixed other issues should have their own bug report.
https://bugs.winehq.org/show_bug.cgi?id=28982
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mailRoxas@gmail.com, | |winetest@luukku.com
https://bugs.winehq.org/show_bug.cgi?id=28982
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=28982
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #31 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Jari Vetoniemi from comment #29)
Game works, and sound/music plays. The background music does not loop properly however, instead keeps repeating the last 2-3 seconds of the end of the song.
Thanks for testing, resolving as fixed. Please open a new bug report for the remaining problem.
https://bugs.winehq.org/show_bug.cgi?id=28982
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #32 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 2.1.