http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #118 from Jörg Höhle hoehle@users.sourceforge.net 2012-01-03 10:46:59 CST --- I've thought more about timelines and start thresholds and came to the conclusion that winealsa needs start_threshold = alsa_period + mmdevapi_period + a little like 3ms or 1/3 mmdevapi_period The "a little" allows event delivery to be delayed by as much, when the system is highly loaded. Only then is underrun free behaviour designed into the code in the worst case scenario (comment #16 without even prefill).
This is based on the consideration that ALSA's avail is unlike mmdevapi's padding: Observe avail = buffer_size and you've hit an underun (with hw:0 and probably dmix). Observe GetCurrentPadding = 0 and you have one period time to supply data. Also, ALSA's hw:0 and dmix operate in period-sized chunks, so ALSA should always have at least own period of data that it can consume.
Currently, I'm unsure whether start_threshold is the way to go or whether to write a lead-in, because I don't know yet how to mix that with the need for trailing silence or when exactly to write trailing silence given the PulseAudio bugs that lead to unreliable snd_pcm_avail_update values.