http://bugs.winehq.org/show_bug.cgi?id=33045
--- Comment #14 from Andrew Eikum aeikum@codeweavers.com 2013-03-08 11:13:29 CST --- Created attachment 43852 --> http://bugs.winehq.org/attachment.cgi?id=43852 Updated: winmm: Truncate buffers to align to frame size
(In reply to comment #12)
Unlike XP, w95 reports no GetPosition test failure
So we have inconsistent behavior across Windows versions. I'm leaning towards the truncate patch, since it exists and is less invasive than tracking bytes.
Your patch is partly wrong. You cannot mix frame rounding ops from the ACM target (PCM) domain with byte counts from the ACM source domain, they don't have the same "dimension". That's a type error.
Yes, good catch.
Regarding the use of the ACM, interesting tests involve IMAADPCM (blocksize 256 or such) and the defunct winemp3 (blocksize 1).
In fact, winecfg's Test Sound button uses IMAADPCM with block size 2048.
I believe we should let the ACM count src bytes as the ACM likes to do and solely round frames on the PCM target side. Perhaps we should then verify that the ACM gives us a multiple of frames.
This is getting pretty far into theoretical territory. But it's not a bad idea, since non-block-aligned buffers make us deadlock. I've added that to the patch.
(In reply to comment #13)
Another possibility for handling bytes not matching ACM or PCM block alignment is: after the header is consumed (ignoring remainder bytes), bump GetPosition to follow, i.e. pretend all bytes were played. IOW, GetPosition matches the sum of dwBufferLength. This is to work-around the weakness of the WINMM API that one receives no feedback about how many bytes were relevant in waveOutWrite.
I'm not opposed to this, but I think it's too invasive to justify, unless we have an application that needs it.