http://bugs.winehq.org/show_bug.cgi?id=33045
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2013-02-28 06:39:44 CST ---
Before that commit [...] audio was missing
That's not a good starting point, but let's see. There's nothing obviously wrong with the patch. Things to try: - Does warn+heap make a difference? - What does Valgrind say? - Use +relay once. Does any of the <20 waveOut* calls fail? - Try out the individual hunks of the offending patch, which one makes a difference?
- Add TRACE to waveOutWrite+(Un)Prepare to reveal dwBufferLength and dwFlags.
Is the number of bytes not a multiple of nBlockAlign (4 from 44100x16x2)? I've never checked whether the new winmm/waveform.c code handles that well.
Something already gets weird after the second waveOutWrite/WOD_PushData. No call to AC_GetBuffer, as if 0 frames (or < 4 bytes) were supplied. What did the second header contain?
After the third call, we see the GetBuffer call asking for 4095 frames, and that's the last trace from thread 55. Your backtrace indicates that it may be looping forever inside WOD_PushData.
- Please instrument both loops in WOD_PushData with TRACE of device->first%p, device->playing, device->last, device->ofs_bytes%u, copy_bytes, queue_bytes and queue%p (the first loop before the if, the second best before memcpy).
It's also weird that the app sends out a single initial header of 4095 frames, then waits for completion callback before sending the second header. That will stutter. Indeed: 0022:trace:alsa:alsa_write_data XRun state avail 3624, recovering
Yet none of that explains the change in behaviour that the patch causes.