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".