[Bug 27087] New: Space Empires: Star Fury hangs with sound enabled (Alsa full hw. acceleration)
http://bugs.winehq.org/show_bug.cgi?id=27087 Summary: Space Empires: Star Fury hangs with sound enabled (Alsa full hw. acceleration) Product: Wine Version: 1.3.19 Platform: x86 URL: http://www.fileplanet.com/130638/130000/fileinfo/Space -Empires:-Starfury-Demo OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: winmm&mci AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com CC: hoehle(a)users.sourceforge.net Created an attachment (id=34522) --> (http://bugs.winehq.org/attachment.cgi?id=34522) plain terminal output The game becomes unresponsive when sounds are enabled and Alsa is set to full hw. acceleration (default). The easiest way to reproduce the issue in the demo by choosing <Credits> from the main menu then click on <Close>. Another occurrence of the problem is when you try to create a new game: the game hangs after you've entered the name of your ship and commander. Workaround: Alsa with 'emulation' mode. Note #1 (when testing): in-game music must be disabled otherwise the game hits bug #2748. Note #2: if you encounter mostly black screen after starting the game you need to change ORM to backbuffer. To reproduce the problem in the demo: 1) Install the demo as usual. 2) Launch the demo by StarFury.exe the first time: this will create the corresponding registry entry for the game. Quit the launcher and fire up regedit. Look for the key under HKCU/Software/Malfador Machinations/Star Fury. Change the value of 'Play Music' from true to false. 3) Launch the demo again (now with disabled music). In the main menu select <Credits>. When you've seen enough of it click on <Close>: the game will hang. The problem didn't occur in Wine-1.3.16: 15ad749eced53e0c33454970bfc2bdb58b64f92b is the first bad commit commit 15ad749eced53e0c33454970bfc2bdb58b64f92b Author: Jörg Höhle <hoehle(a)users.sourceforge.net> Date: Sat Mar 26 07:44:22 2011 +0100 Revert "winmm: Fix PlaySound so it doesn't block when another sound is already playing.". This reverts commit f44bc89bc41b2b8d75eeb4fc02f5aa587d84c13c. Let the player thread call waveOutReset itself instead. :040000 040000 c2dad4069a0edd88b5e2a1f917530f181d4ffb08 344143fca0150b28cf8473c9e62d81f1f89b6454 M dlls Fedora 14 32-bit Kernel 2.6.38.5 Alsa 1.0.24 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) If you need a log with specific debug channels enabled, just ask... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 GyB <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression --- Comment #1 from GyB <gyebro69(a)gmail.com> 2011-05-07 06:00:46 CDT --- Added some keywords. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #2 from GyB <gyebro69(a)gmail.com> 2011-05-07 06:10:53 CDT --- Created an attachment (id=34523) --> (http://bugs.winehq.org/attachment.cgi?id=34523) backtrace generated by winedbg This is a backtrace while the game seems to be unresponsive. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #3 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-05-10 09:35:54 CDT --- Please attach a +tid,+winmm,+mmsystem,+wavemap log. Adding +wave,+dsound will probably get too huge and obscure. +tid is important when threads are involved. BTW, the demo seems hindered by a couple of regressions or other whoes, bug #27062 among them. So far, I only managed to start it with wine-1.2.2. And it only starts in full-screen mode, although it will then open a window instead of really using the full screen, but in hangs in Wine's virtual desktop mode. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #4 from GyB <gyebro69(a)gmail.com> 2011-05-10 11:17:25 CDT --- Created an attachment (id=34593) --> (http://bugs.winehq.org/attachment.cgi?id=34593) +tid,+winmm,+mmsys,+wavemap debug log -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #5 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-05-11 04:09:33 CDT --- I'm sorry I cannot reproduce the hang in the demo, using a single core laptop with Ubuntu Intrepid. I finally managed to start it in wine-1.3.19. The key was to enable full screen mode in winecfg, although the app opens a window. I can enter and exit the credits, select then cancel "new game" and hear the sounds such as Sounds\UIButtonPress.wav. Do you have a multi-core machine? Do you know how to switch other cores off (I don't know how to do that on my Mac), does it still happen then? ALSA HW accel. must be used because the game uses dsound. With emulation mode, dsound already has winmm's sound device open, hence PlaySound fails -- unless you use Maarten's patch to enable multiple opens in winealsa (untested). What I don't understand about how the app could possibly hang is: the sounds are extremely short. Thus they should have finished playing long before you get a change to click the next button. So typically PlaySound won't enter the WaitForSingleObject(psLastEvent, INFINITE) branch. However, your trace shows that thread 0036 send a single waveOutWrite and never terminates. There should be 2 for the 2 buffers. Something is weird about your log. The first UIButtonPress.wav right at the beginning terminates without a single waveOutWrite(). You may add some traces in proc_PlaySound to find out why it terminates early, e.g. trace bPlaySoundStop + print the return value of mmioSeek and mmioRead. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 GyB <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #34593|0 |1 is obsolete| | --- Comment #6 from GyB <gyebro69(a)gmail.com> 2011-05-11 11:57:16 CDT --- Created an attachment (id=34642) --> (http://bugs.winehq.org/attachment.cgi?id=34642) +tid,+winmm,+mmsys,+driver,+wavemap debug log This time I've added +driver to the log. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #7 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-05-12 02:29:35 CDT --- The above commit is not the cause of your trouble. Proof: it's all about aborting a PlaySound player when the next PlaySound happens. However your log shows that even the first playsound is in trouble, when there's nothing to abort. I'd start with a +all log, especially looking at +mmio. It's abnormal that waveOutPrepare is followed by waveOutReset without intervening waveOutWrite. It looks like mmioRead randomly returns <1, aborting the player? That's the initial problem. Please investigate that. mmioRead doesn't yet explain why a later invocation of PlaySound hangs. Also have a look at +wave,+dsound. Perhaps the concurrent use of ALSA by dsound is related to the issue? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #8 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-05-24 16:10:39 CDT --- Could you replace Starfury Demo\Sounds\UIButtonPress.wav with something that plays longer (> 0.5 seconds) and retry? Please replace all short .wav file from the app with long ones and retry. Also, what happens if you set win.ini[Sounds] to one of those very short files and issue the MCI sound command a few times? Your log shows that ALSA is given initial data but it seems to never start playing, although Wine sets start_threshold to 1 in waveout.c:wodOpen. Your log reveals this selection of parameters ALSA_TraceParameters access=MMAP_INTERLEAVED ALSA_TraceParameters format=S16_LE ALSA_TraceParameters channels=2 ALSA_TraceParameters buffer_size=5644 ALSA_TraceParameters rate=44100 ALSA_TraceParameters buffer_time=127981 # near 120000 Wine asked for ALSA_TraceParameters periods_min=5 periods_max=7 ALSA_TraceParameters period_size=940 ALSA_TraceParameters period_time=21333 # near 22000 Note that 21333 is exactly 1024 samples at 48000 per second -- an indication that dmix is resampling from 44100 to 48000? The first (and only) write yields: wodWrite (0, 0x1401f20, 00000020); wodPlayer_ProcessMessages Received WINE_WM_HEADER 1401f20 wodPlayer_FeedDSP Setting time to elapse for 0x1401f20 to 1088 wodPlayer_WriteMaxFrags Writing wavehdr 0x1401f20.0[1088] wodPlayer_WriteMaxFrags dwWrittenTotal=1088 wodPlayer_NotifyCompletions still playing 0x1401f20 (1088/0) wodPlayer waiting 6ms (21,6) The last 2 lines repeat N times as Wine wakes up every 6ms but never sees completion from ALSA. What does snd_pcm_avail_update() yield in wodPlayer_FeedDSP? Perhaps Wine should get an underrun because it does not send more data? Of course, all this ALSA specific stuff does not answer the question why your machine hangs and mine (lspci -v: Intel Corporation 82801F... (ICH6 Family) AC'97 Audio Controller (rev 03)) does not. What happens if you replace snd_pcm_avail_update() in winealsa/waveout.c:wodPlayer_FeedDSP with snd_pcm_avail()? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #9 from GyB <gyebro69(a)gmail.com> 2011-05-25 11:01:07 CDT --- (In reply to comment #8)
Could you replace Starfury Demo\Sounds\UIButtonPress.wav with something that plays longer (> 0.5 seconds) and retry? Please replace all short .wav file from the app with long ones and retry. The replacement sounds (duration > 0.5 second) play fine in the game and no freezing occurs.
Also, what happens if you set win.ini[Sounds] to one of those very short files and issue the MCI sound command a few times? wintest.exe mcishell hangs in the same way as the game with those short wavs. No sound was playing and I had to interrupt the shell by <Ctrl+C>.
What happens if you replace snd_pcm_avail_update() in winealsa/waveout.c:wodPlayer_FeedDSP with snd_pcm_avail()? The game hangs in the same way...
So far I've found the following workarounds: 1) setting ALSA to 'emulation' 2) changing 'defaults.pcm.dmix.rate' to '44100' in /usr/share/alsa/alsa.conf. (the default value is 48000 on my system). Changing MaxShadowSize to 0 or -1 doesn't resolve the problem on my system. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #10 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-05-25 12:30:20 CDT ---
what happens if you set win.ini[Sounds] to one of those very short files and issue the MCI sound command a few times? wintest.exe mcishell hangs in the same way as the game with those short wavs. No sound was playing and I had to interrupt the shell by <Ctrl+C>. Great, this is a super simplification of the bug!
The bug is now as simple as it can get. DSound (mmap) is not involved. You need no more than my MCI shell (full source, please add keyword) Playsound writes a single buffer (1088 bytes) to ALSA. This is smaller than ALSA's period_size (940 frames). Nevertheless, Wine expects ALSA to signal that playing ends, by way of snd_pcm_avail_update(). This does not happen. As a result, WOM_DONE is never called, and the player hangs. Surprisingly, I can now reproduce the bug! in Ubuntu Intrepid -- after killing PulseAudio (is that all that changed?) Reproduce with: Add to drive_c/windows/win.ini: [intl]... [Sounds] SystemExclamation=/home/.../UIButtonPress.wav wintest.exe mcishell (see bug #20232, comment #10) sound SystemExclamation wait notify -> hangs BTW, SystemExclamation is the sound alias used by the winmm:mci testsuite. Configure your win.ini as above, run Wine's testsuite and it will now hang. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 Raymond <superquad.vortex2(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2(a)gmail.com --- Comment #11 from Raymond <superquad.vortex2(a)gmail.com> 2011-05-30 20:23:58 CDT --- (In reply to comment #10)
Playsound writes a single buffer (1088 bytes) to ALSA. This is smaller than ALSA's period_size (940 frames).
Then , it is a bug in Playsound Do you mean winealsa should use a smaller buffer ? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #12 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-05-31 16:21:08 CDT --- Created an attachment (id=34973) --> (http://bugs.winehq.org/attachment.cgi?id=34973) +wave,+alsa snippet of correctly playing short sound with Pulseaudio In Ubuntu Intrepid, the bug does *not* show up: + when using plug:hw (which plays at 41000Hz) + when using plug:pulse (= "default") the bug occurs: - when using plug:dmix (which resamples to 48000Hz) - after killing Pulseaudio (=> using dmix) A log with Pulseaudio is attached and shows the pcm_state transition from RUNNING to XRUN that's missing with dmix. cat /proc/asound/card0/pcm0p/sub0/?w_params shows the card's actual sample rate. Maarten's timer driven winealsa replacement is not affected (hmm, I have to check again that it actually emits the UIButtonPress.wav sound). http://repo.or.cz/w/wine/multimedia.git/shortlog Given that winealsa's new mmdevapi.c is based on a periodic timer too, I believe that we should sit out this issue until Andrew & Maarten's "winmm via mmdevapi" comes out.
Do you mean winealsa should use a smaller buffer ? No. ALSA should start playing the little it has, then signal an underrun. It looks like underrun detection is not working. OTOH, Perhaps Wine should not expect ALSA to play less than one period?
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 GyB <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #13 from GyB <gyebro69(a)gmail.com> 2011-07-20 14:26:42 CDT --- The problem still exists in Wine-1.3.24 but already fixed in the git version. The fix came in the form of http://source.winehq.org/git/wine.git/commit/901af51ea32f2d192a598808abab2d1... Thank you -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #14 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-07-21 02:47:38 CDT --- Wait, that commit disables all winmm sound and therefore is no resolution of that bug. What is needed is to know whether the subsequent commit which introduces mmdevapi-based winmm (wave*) sound makes the bug disappear *and* produces audible clicks. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 --- Comment #15 from GyB <gyebro69(a)gmail.com> 2011-07-21 09:14:44 CDT --- (In reply to comment #14)
Wait, that commit disables all winmm sound and therefore is no resolution of that bug. What is needed is to know whether the subsequent commit which introduces mmdevapi-based winmm (wave*) sound makes the bug disappear *and* produces audible clicks.
Hi Jörg, With the subsequent commit [be158e48ad8ee556941bd3f1ff94ca7116680d00] winmm: Implement waveOut* on top of MMDevAPI. the game doesn't hang and I'm getting sound (button clicks and in-game sound effects). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #16 from Alexandre Julliard <julliard(a)winehq.org> 2011-07-22 12:43:57 CDT --- Closing bugs fixed in 1.3.25. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27087 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |be158e48ad8ee556941bd3f1ff9 | |4ca7116680d00 Regression SHA1| |15ad749eced53e0c33454970bfc | |2bdb58b64f92b --- Comment #17 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-11-09 14:50:19 CST --- Alas, now (1.3.31) that mmdevapi does not fill audio with silence anymore, the bug that ALSA may not start when given samples shorter than its period raises its ugly head again. Try playing StarFury's Demo\Sounds\UIButtonPress.wav and it'll hang like the old winmm did. Perhaps we should not reopen this issue and create a new one. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org