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.
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
Jeremy White wrote:
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.
This would probably be the best way for wine. Keep the existing wave mapper code and just add a better converter specifically for this case. Msacm uses the absolute worst possible algorithm that will get the job done so keeping it for compatibility and adding a better one for the wave mapper is a reasonable solution.
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.
Windows 2000 and xp sound systems have a software mixer called kmixer which will convert any and all application output to the format supported by the hardware. Because of this, some newer systems only support 48kHz 16 bit stereo in hardware and rely on kmixer to do the conversions. This is also why the cooperative level settings in direct sound are no longer needed because kmixer lets the application think it has exclusive access to the sound card and that it supports the requested format.
In windows 9x an application has direct and exclusive access to the sound card. Thats the reason for the cooperative levels in direct sound. The wave api gives you the option of using formats only supported by the hardware or using the wave mapper to do the format conversions in software for you. I don't have access to a win9x machine to verify this but my guess is that either mascm is not used for PCM conversions or that it does something extra to deal with it's limitations.
The tests pass on windows so fudging the tests to work around a bug in wine is not the best solution to the problem.
Jeremy White wrote:
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.
I just tried msacm.drv from a windows 95 CD and it didn't work. I also tried msacm32.drv from xp and it also doesn't work. I ran winedump on msacm32.drv from xp and it imports msacm32.dll.
I will try and get msacm32.drv working so we can see what windows really does.
-
Jeremy White -
Robert Reif