http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #99 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-19 04:25:21 CST --- Playing more with ALSA, I convinced myself that a simple combination of period_near and buffer_near is not enough to guarantee identical behaviour on all machines.
Consider dmix at 48000: set_period_near(10ms) -> 21333ms(!) set_buffer_near(30ms) -> 42666ms (= 2x ALSA period) Even buffer_near 40ms wouldn't make a difference...
Do you believe that the current winealsa.drv logic can drive an ALSA device from only 2 periods without underruns, considering that ALSA always wants a full period before submitting anything?
OTOH, using hw:0 set_period_near(10ms) -> 10ms set_buffer_near(30ms) -> 30ms presumably works much better. That's why we need to mention the actual period&buffer sizes when reporting that app X had an underrun.
set_period_near(10ms) set_hw_params_periods(3); or 4 may be a better choice for the current driver.
BTW, in comment #21, I expressed the idea that at the time the first event is received, the mixer already has shoveled one period of data. If you look at testbot job 15962, you'll see that GCP has decreased by one (480) or sometimes 2 periods (960 frames) after the first WaitFor(Event). It always had decreased in EVENTCALLBACK mode.