http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #115 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-23 04:49:04 CST --- It's too early to close this underrun bug. The current design doesn't prevent it. Consider these scenarios: a) 10ms prefill -- This is the Rage use-case. write 10ms iff padding <= 10ms (=period)
b) without prefill. It's the same really. ALSA simply starts 10ms later as data comes in.
c) App takes a little time, calling ReleaseBuffer only 6ms after the event. That doesn't matter, the app has time to supply data until the next callback event.
d) The callback is delayed a little due to system load. This is the killer.
Consider a 10ms ALSA period. At each and every event, ALSA is on the verge of underrun, having consumed the meagre 10ms it was given. If the callback is late, an underrun is due.
Consider a 16ms ALSA period. ALSA won't start at the first event, because the period is not full. This actually does good as it is equivalent to a lead-in. However, at time t=26ms, ALSA has finished playing its 16ms period, whereas mmdevapi has only seen 30ms. 32ms is needed for the next period, hence an underrun is due. Or is likely, depending on the inner ALSA device workings, e.g. hw:0 may start to play the incomplete period and see it filled up at time t=30ms. Whereas we've seen in comment #63 that plug:dmix won't play the incomplete period, yet maybe its internal buffering will allow it to absorb the delay until t=30.
Here's a timeline: 0 10 20 30 40 50 60 70 80 90 100 110 120 |....|....|....|....|....|....|....|....|....|....|....|....|... 10ms |.......|.......|.......|.......|.......|.......|.......|.. 16ms ----- prefill 20----- 20ms are available at time t=10ms 30----- 30ms at t=20ms 40----- 40ms at t=30ms 50-----