[Bug 28723] Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound output path)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=28723

--- Comment #17 from Alexey Loukianov <mooroon2 at mail.ru> 2011-11-02 13:40:13 CDT ---
(In reply to comment #16)
> Thanks for the nice logs and updates, Alexey. Sorry it's taken me so long to
> get to this bug.
> 
You're welcome. IMO you're doing very well working on dsound/mmdevapi Wine
subsystems and you are the person we all should thank for your hard work. No
need to excuse for not being able to fight all the bugs at once due to time
constrains :-).

> I'll try to describe what I think is happening based on the log in comment 3.
> RAGE's audio thread runs in a loop polling IAudioClient::GetCurrentPadding().
> When the current padding value is <= 441, it writes another packet (441 frames)
> of data. But, I think ALSA's period size is being set to something about the
> same size, so when GCP() is called, its value changes in chunks of
> approximately 441 frames. So you see patterns like this (trimmed for clarity):
> ...
> Notice the large skips in GCP() return values. When RAGE finally sees the <=441

Hmm, correct me if I'm wrong but ALSA reports periods per frame being equal to
88 (trace:alsa:AudioClient_Initialize alsa_period_frames: 88). It seems to be
noticeably lower than 441 frames per chunk RAGE seems to be feeding mmdevapi
with.

> I'm attaching a patch here which I hope fixes this. It just doesn't set the
> ALSA period time at all, letting ALSA figure out what it wants to use. I'm not
> sure about this in combination with fixes for Bug 28282, but it would be useful
> to know if this patch works for you.

Tested with this patch applied, with patch from bug #28282, and with both
patches applied at the same time. Also tried to experiment a bit with divider
used to determine requested alsa_period_us (it's 100 by default, I tried to
change it to 10, 200, 500 and 1000 and see if something changes). All the
attempts failed to produce underrun-free result.

My next move was to add extra debug output to the wine-1.3.30-10-gb0652dd with
reverted b0652dd so it would be as detailed as it the output from
wine-1.3.30-10-gb0652dd. Examining resulting logs from stutter-free run I had
found the following:
...
0053:trace:alsa:AudioClient_Initialize Setting ALSA period size to 10000 us.
0053:trace:alsa:AudioClient_Initialize This->bufsize_alsa: 16317
0053:trace:alsa:AudioClient_Initialize This->period_alsa: 441
0053:trace:alsa:AudioClient_Initialize This->period_is: 10000
... strip ...
0053:trace:alsa:AudioRenderClient_GetBuffer (0x491a470)->(2646, 0x2acd880)
0053:trace:alsa:AudioClient_GetCurrentPadding (0x491a470)->(0x2acd84c)
0053:trace:alsa:AudioClient_GetCurrentPadding PCM state: 2, avail: 16317, pad:
0
0053:trace:alsa:AudioRenderClient_ReleaseBuffer (0x491a470)->(2646, 2)
0053:trace:alsa:AudioClient_Start (0x491a470)
... strip ...
007c:trace:alsa:AudioClient_GetCurrentPadding (0x491a470)->(0x352de97c)
007c:trace:alsa:AudioClient_GetCurrentPadding PCM state: 3, avail: 14998, pad:
1319
007c:trace:alsa:AudioRenderClient_GetBuffer (0x491a470)->(441, 0x352de924)
007c:trace:alsa:AudioClient_GetCurrentPadding (0x491a470)->(0x352de8f0)
007c:trace:alsa:AudioClient_GetCurrentPadding PCM state: 3, avail: 14998, pad:
1319
007c:trace:alsa:AudioRenderClient_ReleaseBuffer (0x491a470)->(441, 0)
...

Notice that the first call of GetBuffer that is being done prior calling Start
is done using relatively big buffer size, namely 2646 frames (it is 6*441).
Then the game proceeds with doing some other init tasks it needs and when it
returns back and calls GetCurrentPadding some part of original 2464 buffer had
already been played back (logs show 1319 frames left). Then the game starts
pumping out data to the buffer in 441 bytes chunks until GetCurrentPadding
returns something around 3200-3300 and tries its best to keep the buffer filled
up at approx this level. I hadn't a part of the logs showing buffer fill
process at it's pretty strait-forward: check the padding, add another 441
frames it's too low.

If you would compare this behavior with the one we get after the b0652d commit,
it looks like that the game is suddenly pretty well content with the padding
level of around 882 frames - it only tries to pump-in another 441 frames of
data in case reported padding is around ~450 frames. Question is what had been
changed by the patch that had caused such a dramatic change in the game
behavior. Now I'm trying to dig a bit deeper in patch diffset and try to figure
out the cause.

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