[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 #29 from Alexey Loukianov <mooroon2 at mail.ru> 2011-11-04 10:12:50 CDT ---
(In reply to comment #27)
> BTW, I've trouble understanding both .pdf, It's not entirely clear what the X
> and Y directions are.

Both PDF expose data collected using shell-fu magic from Wine logs running
RAGE/XA2+mmdevapi on my home PC. Here I've got no PulseAudio, emu10k-based
sound card capable of doing HW wavetable synth (not relevant for our
discussion) and HW multiple playback streams mixing (not relevant also) and
alsalib/plugins 1.0.24 compiled from Fedora 14 sources. 

First PDF aggregates experimentally collected data about the duration XA2
requests from mmdevapi depending on the DefaultPeriod size it retrieves from
it. I.e. if mmdevapu AudioClient_GetDivicePeriod returns X default period to
XA2, then XA2 would specify Y duration in the subsequent call to
AudioClient_Initialize(). Graph visualizes most "interesting" part of
dependency, where we've got discontinuity in curve when default period changes
from 104999 to 105000. Supplementary Y axis (right side of graph) visualize the
amount of samples XA2 pumps into mmdevapi before calling AudioClient_Start() -
i.e. it is the initial buffer fill measured in samples. I hadn't took care to
bring main and supplementary Y axis in sync because wasn't interested in it -
my goal was to illustrate discontinuity/jump at DefaultPeriod = 105000 for both
requested duration and size of initial buffer fill-in. All the values used to
plot the graph are available on the first page of PDF, so one wishing to use
them to plot the graph he wants would be able to do it :-).

Second PDF is an attempt to visualize average time gap between subsequent event
fires (and thus between subsequent timer callbacks). It is pretty rough as time
gap is measured in "audio frames" units returned by ALSA and not something
precise like calls to clock_gettime(). Still it's precise enough as the
obtained values are statistical: I took logs representing one minute of
gameplay, greped/awked/sorted/uniqed values returned by ALSA at subsequent
calls to snd_pcm_avail_update(), then calculated the difference between each
N+1 and N records and visualized them. Each bar on the graph represents the
amount of times (and thus it is approx. of frequency) each given difference had
occurred throughout the entire logs. So it is possible to roughly estimate the
timer scheduling jitter as if observed by ALSA. Peak at "-472" means that
between subsequent calls to GetCurrentPadding 472 of samples had been consumed
by ALSA which is roughly 10.7ms. The fact that "bar peaks" area is shifted
above -441 shows that we have systematic error in timer resolution shifted
towards longer times between subsequent callbacks (we request 10ms, in reality
got up to 11.1ms) as observed by ALSA. The cause for this might either be the
scheduling delays and the timer desync/drifts between HW soundcard timer (used
by ALSA) and CPU/chipset timers (used by timer callbacks).

As for the rest of discussion - I would do tonight a couple of test on my linux
PC and on Win7 laptop and then going to comment here on them.

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