http://bugs.winehq.org/show_bug.cgi?id=33045
--- Comment #17 from Jörg Höhle hoehle@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.