Robert Reif wrote:
Jeremy White wrote:
Robert has persuaded me that msacm on Windows does make 'fuzzy' conversions; an 8,000 byte buffer is up sampled to a 47,992 byte buffer instead of the logical (and correct seeming) 48,000 byte buffer. This means that when we go to get the position after playing the answer comes up as 47992 instead of 48,000, which causes a winmm test failure.
The real fix is to fix the wave mapper to do another conversion when the previous one is incomplete. We will have to do this anyway if we ever try to support non PCM formats.
I don't think that is right; the conversion is not incomplete.
In the specific example of 8000 into 48000 (a 6 to 1 ratio), rather than the first source byte going into the first six dest bytes, instead the first source byte goes into the first four destination bytes, and then the second source byte goes into the next six, and so on. That leaves you with an uneven use of the dest buffer, and hence the left over bytes.
So the conversion is, in fact, complete, it's just for some odd reason not aligned on the initial buffer. I wrote a patch in the wavemapper to 'fill' such unaligned conversions, but then when I read it I realized it was a wrong change.
So the only fix I can imagine would be to not use msacm to perform these conversions and have a parallel set of converters do this in an aligned fashion.
But, again, I wonder if Windows doesn't have this exact same behavior but we can never find it because all Windows hardware drivers claim direct support for all of the winmm formats, so Windows never does a software conversion.
Hence, in my humble opinion, this patch remains correct; I believe that Wine does exactly what Windows would do if it faced the same limited hardware functionality.
Further, I don't see any benefit in leaving these tests broken; the reason to do that would be to spur additional development, and I do not think that any further Wine changes are appropriate.
Cheers,
Jeremy