[Bug 33045] Bunch of Heroes freezing on start at the beginning of the intro video

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=33045

--- Comment #2 from Jörg Höhle <hoehle at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.