http://bugs.winehq.org/show_bug.cgi?id=28284
--- Comment #12 from Jörg Höhle hoehle@users.sourceforge.net 2011-09-22 12:52:47 CDT --- Indeed. Add to winealsa.drv/mmdevdrv.c:GetCurrentPadding *out = This->bufsize_alsa - avail_frames + This->held_frames; + ERR("avail %ld/%lu pos: %u held %u\n", avail_frames, This->bufsize_alsa, *out, This->held_frames); }else if(This->dataflow == eCapture){
and you'll see from lines like: warn:alsa:AudioClient_GetCurrentPadding Xrun detected err:alsa:AudioClient_GetCurrentPadding avail 3991/3763 pos: 0 held 0 where avail > buffer_size that the app entered an underrun. The underrun slowly grows: err:alsa:AudioClient_GetCurrentPadding avail 28017/3763 pos: 0 held 0
As I observed in wine-devel, ALSA plays silence during underruns. As there's no mechanism in Wine to recover from an underrun, sound appears lost.
It's lost until you get back to the menu, where waveOutPause is used, allowing to resync, so you hear the clicks again.
Without my patch, waveOutWrite apparently calls PushData early enough to prevent the underrun for some time. Random system load => delay => underrun.
Wine needs a mechanism to recover from underruns. I'll think of one, but don't hold your breath.