http://bugs.winehq.org/show_bug.cgi?id=14717
--- Comment #79 from Alexander E. Patrakov patrakov@gmail.com 2010-12-27 00:31:59 CST --- Raymond, thanks for your answers. However,
1) Your answer to statement 5 seems to be in contradiction with my test in comment 74, which used the hardware audio device via alsa, with no jack running. Could you please suggest what's different in the formulations of the test and the statement?
2) You seem to be confused by my use of jack in the earlier testcase in comment 4. It is completely irrelevant to this bug. I think that an equivalent testcase (i.e., something that records the digital output of wine, so that the runs of identical samples can be clearly seen) can be done using the "tee" ALSA PCM, without jack. Should I do this and post instructions?
By your own words, wine must provide mixing and resampling on its own, as a fallback. All I want is for this fallback (unfortunately triggered, because there is no equivalent of windows logic "kmixer can automatically adjust the sampling rate to the maximum of the playing streams" in wine) not to suck as badly as it does now. So wine does need a better internal resampler.
As for your comment about the CPU-intensive resampling: I think it would be more reasonable to require that the default sample rate conversion algorithm in wine matches the quality of the default algorithm in Windows, and that the quality is adjustable via winecfg (with the patch attached to this bug, it is adjustable only by a registry setting).
I think I can reverse-engineer the Windows logic by running Windows 2000 or XP in a patched kvm (so that it logs the commands to set the emulated hardware sampling rate, as well as the samples) and playing some test wav files. Would that be an acceptable test from a legal viewpoint?