[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 #17 from Jörg Höhle <hoehle at users.sourceforge.net> 2013-03-08 15:14:55 CST ---
Here are results from WAVE_FORMAT_IMA_ADPCM on a real w2k machine. The ADPCM
parameters are as known from winmm/tests/wave.c.

wave.c:1628: testing 4095 bytes then 4095 bytes
wave.c:1667: Test failed: after position: 15150 samples
wave.c:1673: Test failed: after position: 7679 bytes

wave.c:1628: testing 4096 bytes then 4095 bytes (or 4095 then 4096)
wave.c:1667: Test failed: after position: 15655 samples
wave.c:1673: Test failed: after position: 7935 bytes

wave.c:1628: testing 4096 bytes then 4096 bytes
wave.c:1667: Test failed: after position: 16160 samples
wave.c:1673: Test failed: after position: 8191 bytes

The order of headers does not matter. Clipping to 256 bytes blocksize is
obvious. I've not checked the exact values, but it looks like ACM's
cbSrcLengthUsed is used from each header to limit GetPosition, dwHeaderLength
being irrelevant.

The test may not be trustworthy should ADPCM output length depend on the data,
because I fed it null bytes, no valid IMA_ADPCM data blocks.

I haven't checked whether one can conclude from such data whether w2k's winmm
internally counts in bytes or in samples (cf. bug #23079, comment #4). The data
is consistent with
 bytes = MulDiv(samples, nAvgBytesPerSec, nSamplesPerSec);
For sure it makes WINMM_FramesToMMTime smell wrong.

-- 
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.