http://bugs.winehq.org/show_bug.cgi?id=30639
Bug #: 30639 Summary: Audio stuttering and performance drops in Star Wolves 3 Product: Wine Version: 1.5.3 Platform: x86 URL: http://www.gamershell.com/download_8237.shtml OS/Version: Linux Status: UNCONFIRMED Keywords: download, regression Severity: normal Priority: P2 Component: directx-dsound AssignedTo: wine-bugs@winehq.org ReportedBy: gyebro69@gmail.com CC: patrakov@gmail.com Classification: Unclassified Regression SHA1: 275dfb83f2371a476b615b260465afb3cdf67f32
Due to a recent commit in Wine I get severe audio stuttering as well as slowdowns in certain games. This seems to affect only a small number of games, the vast majority of my games are still running fine. Whether these games are buggy ones or it is indeed a problem with the patch I can't decide as I don't have Windows installed to check how these games behave under native Windows.
275dfb83f2371a476b615b260465afb3cdf67f32 is the first bad commit commit 275dfb83f2371a476b615b260465afb3cdf67f32 Author: Alexander E. Patrakov patrakov@gmail.com Date: Mon May 7 00:06:13 2012 +0600
dsound: Added a windowed-sinc resampler.
:040000 040000 8ecb8b2fbc5c65c2066aaf9a5e8c58104996c5ab 3768c38fdafc656c5e18e14ad70884ea7864b758 M dlls :040000 040000 680c52a0ebe164ca9b6a42d40c6521a91ae86e96 83407150c9beff0aa69d2d2e017b522543ac347f M tools
Star Wolves 3: Civil War (v1.12, Steam): audio playback is glitch-free and performance is okay (well above 60 fps) in the menus and during the tutorial mission. When I advance in the game or when I load a saved game I get severe audio stuttering and framerate drops below 15 fps. This makes the game hardly playable. If I quit playing and go back to the main menu, everything is back to normal. The demo for the game is protected with Starforce so it cannot be tested.
Droplitz (Steam version): this is a puzzle game. A certain sound effect is intended to play when I create a path for the 'drops' and they make their way to their goal. When this happens I observe the same audio stuttering and performance drops. It lasts only for 2-3 seconds so it's not so severe.
Armored Fist 3: audio (both music and speech) are stuttering heavily and it affects performance too. Link to the demo added to URL. There is no music in the demo, but you should observe the problem with speech after starting a new game.
HoverAce: the same stuttering in audio and slowdowns can be observed. No demo available.
Terminal output doesn't show anything related.
Fedora 16 x86 Kernel 3.3.4-3.fc16.i686.PAE Alsa 1.0.25 Pulseaudio is not running Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #1 from Alexander E. Patrakov patrakov@gmail.com 2012-05-10 13:05:31 CDT --- This slowdown is an expected consequence of using a high-quality (i.e. same quality as Widows XP) resampler. Your CPU is just not fast enough to resample that many concurrent audio streams from the sample rate used by the game to the default output sample rate used by Wine.
Some suggestions:
1) Recompile dlls/dsound with -O3 -ffast-math -msse3 in CFLAGS. This alone should give a 2x speedup to the resampler.
2) Avoid resmpling if possible - that's what Windows does. To achieve this, open Regedit and create the HKCU\Software\Wine\DirectSound\DefaultSampleRate registry string value. Try putting 44100 and 48000 in it. With the value that matches the sample rate of the game's sounds, the CPU usage will return to its old value below 100%.
I.e. there are the following possible improvements in Wine without sacrificing sound quality:
1) Group secondary buffers by sample rate. Mix each group separately, resample only the result, then mix the result of resampling.
2) Return a non-zero CPU cost of mixing, in hope that an application will create less streams to mix.
3) Use SSE
4) Try to imitate the Windows way of selecting the primary buffer sample rate more thoroughly (I.e. I guess that the default sample rate should not exist). If that fails and the app didn't set an explicit rate, just set it to the sample rate of the first secondary buffer, even though this violates the spec.
(2) and (3) are low-hanging fruit, (4) may be possible, but (1) requires more refactoring that I am able to do.
http://bugs.winehq.org/show_bug.cgi?id=30639
Alexander E. Patrakov patrakov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #2 from Andrew Eikum aeikum@codeweavers.com 2012-05-10 13:26:57 CDT --- (In reply to comment #1)
I.e. there are the following possible improvements in Wine without sacrificing sound quality:
- Group secondary buffers by sample rate. Mix each group separately, resample
only the result, then mix the result of resampling.
This is a good idea, and shouldn't be too hard. I'll give it a close look, though it will have to wait until after the rest of my cleanup patches are in.
- Return a non-zero CPU cost of mixing, in hope that an application will
create less streams to mix.
I'd be very surprised if there were more than one or two applications that actually use that parameter. Not a bad idea on principle, but I doubt it will help.
- Recompile dlls/dsound with -O3 -ffast-math -msse3 in CFLAGS.
Strikes me as a good idea. Are you still planning to work on this, Alexander? I'd be interested to hear results from GyB if these flags improve things
- Try to imitate the Windows way of selecting the primary buffer sample rate
more thoroughly (I.e. I guess that the default sample rate should not exist). If that fails and the app didn't set an explicit rate, just set it to the sample rate of the first secondary buffer, even though this violates the spec.
This is worth experimenting with, but creating heuristics that work well is always tricky (e.g. which rate to choose, what to do if the preferred rate changes while playing, etc).
http://bugs.winehq.org/show_bug.cgi?id=30639
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |performance CC| |adys.wh@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #3 from Alexander E. Patrakov patrakov@gmail.com 2012-05-10 13:54:00 CDT --- Andrew, could you please send a revert of my patch to wine-patches and mention my permissopn? It caused a more severe bug than it fixed, and I can't do this myself right now (writing this from a mobile phone).
As for your planned cleanups regarding the use of floating point for volume adjustments, I think they have to be redone for (1) to become possible. Namely, currently volume is applied after resampling, and for (1) to work, it needs to happen before resampling (maybe in get_current_sample()), and the mono2stereo expansion has to be moved from put to get, too.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #4 from Andrew Eikum aeikum@codeweavers.com 2012-05-10 14:02:58 CDT --- I think it's too early to revert the patch. We don't know how widespread this problem is. I think a better option would be to add a registry setting (maybe a winecfg toggle) to go back to the zero-order hold. But let's let it get some testing during the next release before we decide how to tackle the problem.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #5 from Alexander E. Patrakov patrakov@gmail.com 2012-05-10 14:31:53 CDT --- My opinion is that zero-order hold must die, unconditionally. If a fallback is needed, let's use linear interpolation - that's what Windows XP does at the worst quality setting, that's what ALSA does if you have no alsa-plugins installed, and it is better than zero-order hold. On Sunday, I will make a patch.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #6 from GyB gyebro69@gmail.com 2012-05-10 14:40:35 CDT --- (In reply to comment #1)
Some suggestions:
- Recompile dlls/dsound with -O3 -ffast-math -msse3 in CFLAGS. This alone
should give a 2x speedup to the resampler.
This helps to overcome the problem in Armored Fist 3 and in Droplitz. The problem still occurs in Star Wolves 3, maybe less frequently. A sure way to reproduce the problem in SW3 is to alt-tab out of the game, then alt-tab back to it. This didn't happen before the patch.
- Avoid resmpling if possible - that's what Windows does. To achieve this,
open Regedit and create the HKCU\Software\Wine\DirectSound\DefaultSampleRate registry string value. Try putting 44100 and 48000 in it. With the value that matches the sample rate of the game's sounds, the CPU usage will return to its old value below 100%.
This didn't change anything.
btw. I have an AMD Athlon 64 x2 4200+ cpu, running @2.2 GHz.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #7 from Alexander E. Patrakov patrakov@gmail.com 2012-05-12 12:03:41 CDT --- Created attachment 40136 --> http://bugs.winehq.org/attachment.cgi?id=40136 low-quality resampler for games
Attached patch is a stop-gap solution. Please verify it.
The patch implements a linear resampler and uses it if there are more than 4 secondary buffers (which is unlikely for music players). This resampler offers exactly the same quality as Windows XP at its worst quality setting. This is still better than the zero-order hold that was in Wine before my work on resampling.
http://bugs.winehq.org/show_bug.cgi?id=30639
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|download | URL|http://www.gamershell.com/d | |ownload_8237.shtml |
--- Comment #8 from GyB gyebro69@gmail.com 2012-05-12 13:08:45 CDT --- (In reply to comment #7)
Created attachment 40136 [details] low-quality resampler for games
Attached patch is a stop-gap solution. Please verify it.
The patch implements a linear resampler and uses it if there are more than 4 secondary buffers (which is unlikely for music players). This resampler offers exactly the same quality as Windows XP at its worst quality setting. This is still better than the zero-order hold that was in Wine before my work on resampling.
The patch fixes the problem in Star Wolves 3 as well as in three other games. Armored Fist 3 seems to be immune to the patch and it still produces garbled audio.
From now on, I'm referring only to the Star Wolves game to avoid making the bug
report invalid (one problem per bug). Therefore I removed the download keyword.
Alexander, I have a spare copy of SW 3 available on Gamersgate. I can gift it to you if you'd like to investigate the problem with this particular game. There's no guarantee that the problem can be reproduced with that version as I've tested the Steam version of the game. PM me if you're interested.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #9 from Alexander E. Patrakov patrakov@gmail.com 2012-05-12 13:57:32 CDT --- It is very strange that Armored Fist 3 is fixed by changing the optimization level but not by switching to the linear resampler. Could you please retest, reconfirm that the regression in this game is indeed caused by my patch, guess how the sound in this game is different from others, or otherwise try to extract some sense from it?
For games that are fixed by both methods, could you please compare CPU usage in the unfixed and both of fixed variants of wine?
As for the removal of the download keyword - I am not convinced. Let's use this bug as a catch-all for problems with a resource-hungry resampler.
Just to give me a better understanding of the scale of the problem, could you please add tracing of the sample rate (dsb->pwfx->nSamplesPerSec) to DSOUND_MixOne (in dlls/dsound/mixer.c)? The goal is to know how many different secondary buffers are used by each affected game, what are their sample rates and thus what level of performance is needed.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #10 from GyB gyebro69@gmail.com 2012-05-12 23:44:32 CDT --- (In reply to comment #9)
It is very strange that Armored Fist 3 is fixed by changing the optimization level but not by switching to the linear resampler. Could you please retest, reconfirm that the regression in this game is indeed caused by my patch, guess how the sound in this game is different from others, or otherwise try to extract some sense from it?
I retested Armored Fist 3 and Star Wolves 3 and can confirm that the problem is caused by your commit. The symptoms are the same with both games: audio has artifacts (stuttering) and audio playback speed is decreased considerably (drawl in speech in AF 3, slowed down music playback). Overall game performance (framerate) also suffers a lot.
For games that are fixed by both methods, could you please compare CPU usage in the unfixed and both of fixed variants of wine?
I tested those 2 games with the following Wine versions: *1.5.3 (considered good) *1.5.4 (bad) *1.5.4 with CFLAGS optimization in dlls/dsound *1.5.4 with your low-quality patch
CPU usage in Armored Fist 3 doesn't change a bit with any of the tested Wine versions. Htop shows steady 60% cpu usage while I'm in the menus, and 80% in mid-game. As a reminder, CFLAGS optimization makes the problem go away, but the low-quality patch doesn't touch the problem.
There is much variation in cpu usage in SW 3: Wine 1.5.3: htop shows that the game is running 5 threads, but only one of them is active and it always consumes 100% cpu power whether I'm in the menus or in mid-game. Cpu usage doesn't change noticeably during gameplay.
Wine-1.5.4 (unpatched): there are 2 active threads running. Thread (1) always consumes 120-130%, thread (2) consumes 20-25% while I'm in the menus and everything seems to be fine. When the problem occurs, cpu usage for thread (2) raises to 80-90%, thread (1) remains 120-130%.
Wine 1.5.4 with CFLAGS optimization: basically the same as with an unpatched Wine: thread (1):120-130%, thread (2):20-25%, then it raises to 80-90% when the problem occurs.
Wine 1.5.4+low-quality resampler: thread (1): 110-120%, thread (2):10-15% in the menus. While in mid-game thread (2) raises only to 25-30%, so it's considerably lower than with an unpatched Wine or with CFLAGS optimization.
As a reminder CFLAGS optimization doesn't touch the problem in SW 3, but the low-quality patch does.
Just to give me a better understanding of the scale of the problem, could you please add tracing of the sample rate (dsb->pwfx->nSamplesPerSec) to DSOUND_MixOne (in dlls/dsound/mixer.c)? The goal is to know how many different secondary buffers are used by each affected game, what are their sample rates and thus what level of performance is needed.
Could you attach a small patch that enables such traces? I don't have enough programming skill to modify the source.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #11 from Alexander E. Patrakov patrakov@gmail.com 2012-05-13 08:46:19 CDT --- (In reply to comment #10)
(In reply to comment #9)
It is very strange that Armored Fist 3 is fixed by changing the optimization level but not by switching to the linear resampler. Could you please retest, reconfirm that the regression in this game is indeed caused by my patch, guess how the sound in this game is different from others, or otherwise try to extract some sense from it?
I retested Armored Fist 3 and Star Wolves 3 and can confirm that the problem is caused by your commit. The symptoms are the same with both games: audio has artifacts (stuttering) and audio playback speed is decreased considerably (drawl in speech in AF 3, slowed down music playback). Overall game performance (framerate) also suffers a lot.
For games that are fixed by both methods, could you please compare CPU usage in the unfixed and both of fixed variants of wine?
I tested those 2 games with the following Wine versions: *1.5.3 (considered good) *1.5.4 (bad) *1.5.4 with CFLAGS optimization in dlls/dsound *1.5.4 with your low-quality patch
CPU usage in Armored Fist 3 doesn't change a bit with any of the tested Wine versions. Htop shows steady 60% cpu usage while I'm in the menus, and 80% in mid-game. As a reminder, CFLAGS optimization makes the problem go away, but the low-quality patch doesn't touch the problem.
Thanks, this is very useful to know. I have downloaded the demo, and it indeed doesn't look like a resampler performance problem. In fact, on my computer, it exists before the resampler patch, and even in 1.5.3. Strangely, CFLAGS somewhat (but not fully) help even there. So it is definitely not related to my patch, although for you it exposed the problem. Let's indeed open a separate bugreport for it.
There is much variation in cpu usage in SW 3: Wine 1.5.3: htop shows that the game is running 5 threads, but only one of them is active and it always consumes 100% cpu power whether I'm in the menus or in mid-game. Cpu usage doesn't change noticeably during gameplay.
Wine-1.5.4 (unpatched): there are 2 active threads running. Thread (1) always consumes 120-130%, thread (2) consumes 20-25% while I'm in the menus and everything seems to be fine. When the problem occurs, cpu usage for thread (2) raises to 80-90%, thread (1) remains 120-130%.
Wine 1.5.4 with CFLAGS optimization: basically the same as with an unpatched Wine: thread (1):120-130%, thread (2):20-25%, then it raises to 80-90% when the problem occurs.
Wine 1.5.4+low-quality resampler: thread (1): 110-120%, thread (2):10-15% in the menus. While in mid-game thread (2) raises only to 25-30%, so it's considerably lower than with an unpatched Wine or with CFLAGS optimization.
As a reminder CFLAGS optimization doesn't touch the problem in SW 3, but the low-quality patch does.
Well, this confirms the "resampler is too slow" theory for this game.
Just to give me a better understanding of the scale of the problem, could you please add tracing of the sample rate (dsb->pwfx->nSamplesPerSec) to DSOUND_MixOne (in dlls/dsound/mixer.c)? The goal is to know how many different secondary buffers are used by each affected game, what are their sample rates and thus what level of performance is needed.
Could you attach a small patch that enables such traces? I don't have enough programming skill to modify the source.
Here it is, inline:
--- a/dlls/dsound/mixer.c +++ b/dlls/dsound/mixer.c @@ -598,7 +598,7 @@ static DWORD DSOUND_MixOne(IDirectSoundBufferImpl *dsb, DWORD writepos, DWORD mi * buffer's mixpos, but both must be ahead of writepos. */ DWORD primary_done;
- TRACE("(%p,%d,%d)\n",dsb,writepos,mixlen); + TRACE("(%p,%d,%d) @ %d Hz\n",dsb,writepos,mixlen, dsb->pwfx->nSamplesPerSec); TRACE("writepos=%d, primary_mixpos=%d, mixlen=%d\n", writepos, dsb->primary_mixpos, mixlen); TRACE("looping=%d, leadin=%d\n", dsb->playflags, dsb->leadin);
Then just run the game as follows:
WINEDEBUG=dsound wine game.exe 2>&1 | egrep 'Hz|Mixed'
E.g. for AF3 demo this shows that there is only a single buffer running at 22050 Hz, and the problem is stated as "Mixed at least 0 from all buffers".
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #12 from GyB gyebro69@gmail.com 2012-05-13 10:53:11 CDT --- Created attachment 40160 --> http://bugs.winehq.org/attachment.cgi?id=40160 SW 3 +dsound log
The file contains the relevant part of a +dsound debug log (after egrep 'Hz|Mixed') when running Star Wolves 3 for a few seconds. Intro videos were skipped and I loaded a saved game where the problem occured. Btw. the problem never occurs during the intro videos or while I'm in the menus. Does the log make sense to you?
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #13 from Alexander E. Patrakov patrakov@gmail.com 2012-05-13 11:38:52 CDT --- Yes, it makes sense. SW3 creates one buffer at 44100 Hz and up to 15 buffers at 22050 Hz, and that's enough to overload your CPU. I think that on your CPU Darwinia 2 Demo is also affected (that's what I am benchmarking with), as it creates 32 buffers at 22050 Hz.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #14 from Alexander E. Patrakov patrakov@gmail.com 2012-05-13 11:57:09 CDT --- No, I was wrong about darwinia Demo.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #15 from Alexander E. Patrakov patrakov@gmail.com 2012-05-13 12:19:33 CDT --- I was wrong again. Darwinia Demo is relevant, and the debugging line is wrong. It should be:
TRACE("(%p,%d,%d) @ %d Hz -> %d Hz\n",dsb,writepos,mixlen, dsb->freq, dsb->device->pwfx->nSamplesPerSec);
Darwinia Demo uses 32 buffers with weird and constantly changing sample rates, and resamples them all to 22050 Hz.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #16 from Alexander E. Patrakov patrakov@gmail.com 2012-05-13 12:30:37 CDT --- According to my testing with Darwinia Demo,
1) Something has changed in my system so that SSE2/3 optimizations don't have as much effect as I stated before. So more profiling is needed, and let's drop the idea until it is confirmed independently.
2) 32 streams (as used by Darwinia) is about as much as a Core 2 Duo E6420 @ 2.13 GHz (a top-class CPU from 2007) can handle with the high-quality resampler.
3) Low-quality resampler works. I only need to make the maximum high-quality buffer count a registry setting.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #17 from GyB gyebro69@gmail.com 2012-05-13 12:32:29 CDT --- Just would like to add that I have Darwinia (from Introversion Software) and I also tried the demo version, but I couldn't reproduce the problem with them: both the demo and the full version of Darwinia runs without problems here. Performance is good and there is no audio stuttering.
http://bugs.winehq.org/show_bug.cgi?id=30639
Alexander E. Patrakov patrakov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40136|0 |1 is obsolete| |
--- Comment #18 from Alexander E. Patrakov patrakov@gmail.com 2012-05-13 12:33:32 CDT --- Created attachment 40162 --> http://bugs.winehq.org/attachment.cgi?id=40162 low-quality resampler for games
This is what I am going to send to wine-patches tomorrow. Please review.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #19 from Alexander E. Patrakov patrakov@gmail.com 2012-05-13 12:35:46 CDT --- (In reply to comment #17)
Just would like to add that I have Darwinia (from Introversion Software) and I also tried the demo version, but I couldn't reproduce the problem with them: both the demo and the full version of Darwinia runs without problems here. Performance is good and there is no audio stuttering.
Indeed, the problem is not reproducible with them, but it is a good target for measuring the effects of various patches on the CPU usage.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #20 from Andrew Eikum aeikum@codeweavers.com 2012-05-14 08:14:28 CDT --- I don't have any strong objections to your patch, but just some thoughts.
This adds another codepath, which makes me a little hesitant. Another method to consider is using a lower resolution FIR, which lets us keep just the one codepath. A "problem" here is module bloat. Two FIRs is going to make the binary size quite large.
Does this handle adding/removing buffers? For example, if an app is playing and adds a fourth buffer, does that transition happen correctly?
Instead of triggering the LQ resampler based on the number of buffers, what about using the number of playing buffers? Some apps load lots of buffers, but only play a couple at a time. This could make the previous problem occur more often.
Finally, I'm wondering if fixing this bug should wait until after the rest of my cleanup patches. This bug only has a small handful of applications listed, and we've had no reports from other users or duplicates. It doesn't seem /that/ high priority to me.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #21 from Alexander E. Patrakov patrakov@gmail.com 2012-05-14 09:26:08 CDT --- The transition is handled almost correctly, because no state is kept between the resampler runs. "Almost" because the two resamplers have different latency, so a glitch of less than 1 ms will happen.
As for basing the heuristic on the number of playing buffers, the problem is that it is not readily available.
A different, low-quality FIR might be a good idea, I will play with it.
http://bugs.winehq.org/show_bug.cgi?id=30639
Ruslan b7.10110111@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |b7.10110111@gmail.com
--- Comment #22 from Ruslan b7.10110111@gmail.com 2012-05-17 01:02:03 CDT --- *** Bug 30700 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=30639
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #23 from Erich Hoover ehoover@mines.edu 2012-08-13 09:07:45 CDT --- *** Bug 31458 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #24 from Erich Hoover ehoover@mines.edu 2012-08-13 09:25:04 CDT --- Is it possible that this issue is related in some way to IQualityControl ({56a868a5-0ad4-11ce-b03a-0020af0ba770}) being unimplemented?
http://bugs.winehq.org/show_bug.cgi?id=30639
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |dank@kegel.com Ever Confirmed|0 |1
--- Comment #25 from Dan Kegel dank@kegel.com 2012-08-13 23:15:37 CDT --- Multiple dups -> confirmed new
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #26 from Alexander E. Patrakov patrakov@gmail.com 2012-08-14 00:04:32 CDT --- (In reply to comment #24)
Is it possible that this issue is related in some way to IQualityControl ({56a868a5-0ad4-11ce-b03a-0020af0ba770}) being unimplemented?
No. The resampler is just too resourse-intensive for some games.
See http://www.winehq.org/pipermail/wine-patches/2012-May/114356.html and http://www.winehq.org/pipermail/wine-patches/2012-May/114357.html for two alternative patches and explanation. Please:
* read the text accompanying the first patch, * bring them up to date (if they aren't) and apply one (I don't really care which one) as a band-aid, * then investigate why switching the resampler via the HQBuffersMax registry setting affects the non-audio thread CPU usage in some games (that's what I suspect to be the real bug).
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #27 from Alexander E. Patrakov patrakov@gmail.com 2012-08-14 00:31:00 CDT --- I'd like to add to the text that is possible to set 44100 Hz sample rate and 64 secondary buffers via the in-game settings in Darwinia Demo (instead of the debugging patch referenced in my e-mail but never sent to any list). The 5-year-old CPU can still handle that load without hiccups. So it looks like there is something special in the games affected by this bug that makes the time budget for the resampler significantly less than "100% of one core". Locking issues?
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #28 from Andrew Eikum aeikum@codeweavers.com 2012-08-14 07:37:00 CDT --- Locking issues is a good guess. DSound's thread safety algorithms need a good review. It should be easier to diagnose now that dsound is cleaned up, and the +timestamp channel will come in handy.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #29 from Erich Hoover ehoover@mines.edu 2012-08-14 20:56:38 CDT --- (In reply to comment #26)
No. The resampler is just too resourse-intensive for some games. ...
Ok, well I'm not excessively familiar with DirectSound - but based on reading some of your patch comments I tracked down a document describing how DS uses different samplers: http://msdn.microsoft.com/en-us/library/windows/hardware/ff537758%28v=vs.85%...
As this is not my area of expertise I'll bow out at this point, but if you need any testing then I'd be happy to help.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #30 from Ruslan b7.10110111@gmail.com 2013-01-10 08:24:04 CST --- In GTASA this bug is still present as of wine-1.5.21-109-g136b738. But performance is a bit better than a month or two ago (2-3 FPS vs 0.5-1 FPS). But it still is an order of magnitude slower than before regression.
http://bugs.winehq.org/show_bug.cgi?id=30639
xangel1@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xangel1@mail.ru
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #31 from Ruslan Kabatsayev b7.10110111@gmail.com 2013-03-09 09:06:51 CST --- After having something changed in my system (and I'm not sure what: it might be another kernel or some lib upgraded or anything) I can't reproduce this bug with wine 1.5.25. I thought I'd reverse-bisect, but now I can't reproduce this with 1.5.21 too...
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #32 from Ruslan Kabatsayev b7.10110111@gmail.com --- After accidentally deleting newer savegames and loading the older which lead to bug reproducing, I appear now to reproduce this bug with GTASA again. It's still present in wine-1.7.14-126-g2bb1059.
http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #33 from Alexander E. Patrakov patrakov@gmail.com --- The bug is of course valid. However, because my patches that attempt to fix it were ignored, I am no longer motivated to pursue it further.
http://bugs.winehq.org/show_bug.cgi?id=30639
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=30639
Jonas Jelten jonas.jelten@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.jelten@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=30639
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #34 from Béla Gyebrószki gyebro69@gmail.com --- Still present in 1.7.40. Affects the indie game Foresight on Steam.
Wine-staging contains the linear resampler patch originally written by Alexander E. Patrakov: https://github.com/wine-compholio/wine-staging/blob/master/patches/dsound-Fa...
Fedora 21 Alsa 1.0.28 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev a2)
https://bugs.winehq.org/show_bug.cgi?id=30639
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |michael@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/dsound-Fast_Mi | |xer
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #35 from Ruslan Kabatsayev b7.10110111@gmail.com --- Still present in GTA San Andreas with wine-1.9.23-72-g5cd33bf.
https://bugs.winehq.org/show_bug.cgi?id=30639
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #36 from winetest@luukku.com --- Since wine is fixing regressions now how likely would it to have this fix in wine 2.0?
Or is it too complicated to test? Or some other issues?
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #37 from Andrew Eikum aeikum@codeweavers.com --- (In reply to winetest from comment #36)
Since wine is fixing regressions now how likely would it to have this fix in wine 2.0?
Or is it too complicated to test? Or some other issues?
This bug was caused because we implemented a high quality resampler, which simply requires more CPU power. The patch in staging turns down the quality of the resampler if there are more than 4 buffers to resample. This kind of works, but if I have a high end CPU, I'd rather get the high quality.
I think a smarter heuristic might have a better chance of getting in. For example, we could time how long resampling takes, compare that to the period length, and lower quality if a large percentage of the period is spent resampling.
Another option is to increase the efficiency of our new resampler so it works on older CPUs.
In any case, no such patch exists, and this problem will largely solve itself as users get better CPUs, so it isn't terribly high priority.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #38 from Alexander E. Patrakov patrakov@gmail.com --- Andrew, this "improved" heuristic would be specifically disapproved by me, because it is significantly more complex than the current one, and won't help.
Even older CPUs (e.g a 9-year-old Core 2 Duo E6420) have enough power to resample 64 audio streams on one core with the current high-quality resampler, if allowed to use 100% of this core (proof: darwinia). The real problem is that some unknown problem (locking?) prevents the audio resampler from using more than 3% of the core in some games. We need to diagnose that problem.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #39 from Andrew Eikum aeikum@codeweavers.com --- (In reply to Alexander E. Patrakov from comment #38)
Even older CPUs (e.g a 9-year-old Core 2 Duo E6420) have enough power to resample 64 audio streams on one core with the current high-quality resampler, if allowed to use 100% of this core (proof: darwinia). The real problem is that some unknown problem (locking?) prevents the audio resampler from using more than 3% of the core in some games. We need to diagnose that problem.
Oh, I didn't know that! Thanks for pointing that out, I'll circle back on this one.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #40 from Ruslan Kabatsayev b7.10110111@gmail.com --- (In reply to Andrew Eikum from comment #37)
In any case, no such patch exists, and this problem will largely solve itself as users get better CPUs, so it isn't terribly high priority.
Still I don't quite get what better CPUs you mean. I have Core i7 4765T, and GTASA is still almost as unplayable as it was with i7 930, while on Windows it works perfectly even on Pentium 4.
I'd suppose a somewhat good heuristic might be to detect buffer underruns and switch to lower level in the case of more than 4 buffers. It should be easier to do than measurements of time and comparison of its percentage to other.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #41 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Alexander E. Patrakov from comment #38)
... The real problem is that some unknown problem (locking?) prevents the audio resampler from using more than 3% of the core in some games. We need to diagnose that problem.
I have a save from one of the Fallout 3 DLCs that I keep around because it perfectly reproduces this problem. Do you have any idea what lock might be responsible?
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #42 from Alexander E. Patrakov patrakov@gmail.com --- (In reply to Erich E. Hoover from comment #41)
I have a save from one of the Fallout 3 DLCs that I keep around because it perfectly reproduces this problem. Do you have any idea what lock might be responsible?
No.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #43 from winetest@luukku.com --- I could be wrong, but in the staging patch...
float cur_freqAcc = (freqAcc_start + i * dsb->freqAdjustNum) / (float)dsb->freqAdjustDen;
should there be also (float)dsb->freqAdjustNum)
missing (float)
?
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #44 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to winetest from comment #43)
I could be wrong, but in the staging patch...
float cur_freqAcc = (freqAcc_start + i * dsb->freqAdjustNum) / (float)dsb->freqAdjustDen;
should there be also (float)dsb->freqAdjustNum) missing (float)?
It doesn't matter, the division operation will be performed in floats since the denominator is a float. No math in the numerator requires floats.
The staged patch for this is not ideal, what it does is reduce the computation required inside of the mixing lock. I have been spending some energy trying to understand the pieces that go together in the mixing code (honestly, it needs to be reorganized) and I believe that it is possible to reduce the amount of code that occurs within the lock. If I am successful in this endeavor then the re-sampling operation can occur outside the lock (only the mixing itself will occur within the lock) and that will allow multiple streams to be re-sampled simultaneously, instead of requiring that only one stream be re-sampled at a time.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #45 from Alexander E. Patrakov patrakov@gmail.com --- No, this will not allow resampling multiple streams simultaneously, as all the resampling is currently done in the (single) mixer thread. Moving resampling outside of the lock will still be beneficial, because it will allow other threads (that presumably produce sound) to do useful work while the mixer thread is resampling.
And please don't move resampling to some other thread that already exists -- the problem is that there is no reliable event to trigger it. E.g. some games simply don't unlock their secondary buffers. Also, it is very hard to handle the situation where a game writes some audio data to its secondary buffer speculatively and then corrects it later, because the output also depends on some data immediately preceding what was overwritten.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #46 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Alexander E. Patrakov from comment #45)
No, this will not allow resampling multiple streams simultaneously, as all the resampling is currently done in the (single) mixer thread. Moving resampling outside of the lock will still be beneficial, because it will allow other threads (that presumably produce sound) to do useful work while the mixer thread is resampling.
My plan was to get it outside the lock first and, if that's good enough, then stop there. If that's not good enough then my thought was to have the mixer thread manage a dynamic pool of re-sampler threads. This would be worse than what we do now on a single core system, so I'd obviously like to avoid that if I can.
And please don't move resampling to some other thread that already exists -- the problem is that there is no reliable event to trigger it. E.g. some games simply don't unlock their secondary buffers. Also, it is very hard to handle the situation where a game writes some audio data to its secondary buffer speculatively and then corrects it later, because the output also depends on some data immediately preceding what was overwritten.
I would imagine that if I attempted to do that then it would get shot down on wine-devel pretty quickly.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #47 from Ruslan Kabatsayev b7.10110111@gmail.com --- Still present in wine-2.15-74-g083e61f; patch from wine-staged does seem to fix it.
https://bugs.winehq.org/show_bug.cgi?id=30639
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #48 from Ruslan Kabatsayev b7.10110111@gmail.com --- Still present with GTASA in wine-3.0-rc1.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #49 from Ruslan Kabatsayev b7.10110111@gmail.com --- I noticed that if I enable _any_ nonzero speed optimization in CFLAGS, even -O1 or -Og, I get drastic performance improvement in GTASA, although the sound sometimes still appears choppy. But any attempt to use -msse3, -march=native or -O3 (or combinations thereof) gives small if any improvement. The same picture is when I only recompile mixer.c adding optimization options instead of whole Wine source.
It seems strange that by default Wine doesn't enable any optimizations at all. (Tested on wine-3.1-286-g389c3ad.)
https://bugs.winehq.org/show_bug.cgi?id=30639
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #50 from Andrew Eikum aeikum@codeweavers.com --- (In reply to Ruslan Kabatsayev from comment #49)
It seems strange that by default Wine doesn't enable any optimizations at all. (Tested on wine-3.1-286-g389c3ad.)
How are you building it? It sets -O2 for me, not sure what it keys that off of. In any case, it's an autotools thing, check configure and config.log output.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #51 from Ruslan Kabatsayev b7.10110111@gmail.com --- (In reply to Andrew Eikum from comment #50)
How are you building it? It sets -O2 for me, not sure what it keys that off of. In any case, it's an autotools thing, check configure and config.log output.
I always built it with CFLAGS=-g set as environment variable. Maybe this overwrites the default -O2 instead of appending -g to the flags.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #52 from Andrew Eikum aeikum@codeweavers.com --- Yes, setting CFLAGS in the environment will override configure's default CFLAGS.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #53 from Henri Verbeet hverbeet@gmail.com --- Also, the default is "-g -O2".
https://bugs.winehq.org/show_bug.cgi?id=30639
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/dsound-Fast_Mi |er/patches/dsound-Fast_Mixe |xer |r CC| |nerv@dawncrow.de
https://bugs.winehq.org/show_bug.cgi?id=30639
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #54 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-4.19?
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #55 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to joaopa from comment #54)
Does the bug still occur with wine-4.19?
Yes it does (reproduced in Star Wolves 3 from GOG.com).
https://bugs.winehq.org/show_bug.cgi?id=30639
Kai Krakow kai@kaishome.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kai@kaishome.de
--- Comment #56 from Kai Krakow kai@kaishome.de --- Shouldn't it be relatively simple to just spawn more threads and do parallel resampling by splitting the buffer in half? A heuristic could do this, i.e. if the current buffer took more than 50% CPU time in single thread, and at the same time we have less than 50% CPU usage across the full CPU, we could split the buffers. This cycle could repeat and split buffers in half again if the heuristic barrier is crossed again. A protection would kick in if more than 50% of the CPU threads are reached, i.e. we'd use 4 threads max on a 8-core CPU.
At the end of one mixing cycle, the threads will be synced and maybe we'd need to calculate a remaining mixing window at the adjacent borders of the buffers based on the algorithm used.
This should be pretty simple to implement in a first step by hard-coding the heuristic to use two threads. But spawning and joining threads may have high overhead, so that should be done once at the heuristic barrier so we'd not recreate threads on each buffer cycle.
Without having looked at the code, it seems it already has one worker thread. It could be enhanced by simply putting additional offset and length values into the worker struct, and some boilerplate code around to re-sync the threads to the merged buffer.
Also, I'm not sure if there's an effect library involved which would apply reverb or similar effects. Using parallel threads here is probably not possible. We could still split threads by other parameters, tho, which was outlined in some comments already (e.g. by sample rate) but that may not reliably lower the time needed, it may even potentially have an inverse result because we'd need to combine the groups in a final pass.
https://bugs.winehq.org/show_bug.cgi?id=30639
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions@gmail.com
--- Comment #57 from Berillions berillions@gmail.com --- No news about this bug to implement upstream the staged patch ?
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #58 from Andrew Eikum aeikum@codeweavers.com --- No news. The right fix is to optimize the resampling, probably by doing mixing first and then resampling each independent rate only once.
https://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #59 from Alexander E. Patrakov patrakov@gmail.com --- Andrew, let me repeat the fact from comment #38:
Even older CPUs (e.g a 9-year-old Core 2 Duo E6420) have enough power to resample 64 audio streams on one core with the current high-quality resampler, if allowed to use 100% of this core (proof: darwinia). The real problem is that some unknown problem (locking?) prevents the audio resampler from using more than 3% of the core in some games. We need to diagnose that problem.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla