http://bugs.winehq.org/show_bug.cgi?id=33686
Bug #: 33686 Summary: Diablo III: Audio cuts out after a while of game play Product: Wine Version: 1.5.31 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winealsa.drv AssignedTo: wine-bugs@winehq.org ReportedBy: kdt3rd@gmail.com Classification: Unclassified
After a semi-random amount of time playing the game, the audio all of a sudden stops outputting anything. I am not running pulse or any sound daemon, just using alsa with the output device hard-specified in winecfg.
After trying to trace with the Audio wiki-recommended WINEDEBUG settings, I didn't get very far trying to isolate the problem, so I modified the TRACE in dlls/winealsa.drv/mmdevdrv.c, and when the audio cuts out, it looks like the AudioClient_GetCurrentPadding is called in-between or just slightly one (wrong) side of alsa_write_data, which causes a larger number to be returned than 'normal'. At this point, a lot of the AudioRenderClient_(GetBuffer|ReleaseBuffer) calls start requesting 0 frames. But more importantly, something about that sequence getting out of the normal thread sequence triggers the pad stored in 'in_alsa' in alsa_write_data to become larger than max_period * 3 size. This means that write_limit ends up stuck at 0, so it leaves the alsa_write_data function early and no audio is output...
I write this bug because it seems like the code that is implementing the comment about keeping 3 ALSA/MMDevAPI periods in the ALSA buffer is either flawed, or more likely, I don't understand all the pieces, so I'm not sure how to make a patch to appropriately fix the issue. Any hints on potential patches are appreciated.