http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #29 from Alexey Loukianov mooroon2@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.