http://bugs.winehq.org/show_bug.cgi?id=14717
--- Comment #72 from Alexander E. Patrakov patrakov@gmail.com 2010-12-26 01:05:05 CST --- Raymond, I am not sure that I understand what you demand. Could you please confirm below each of these points whether we agree on it?
1. Windows has kmixer, the component that mixes and resamples sound. In Wine, dsound-based resampling and mixing is done in dlls/dsound/mixer.c, by adding the contents of secondary dsound buffers (stretched or shunk by duplicating or dropping samples - that's important!) into primary.
2. Sound produced by the WaveOut API does not go through dlls/dsound/mixer.c (tested with WinAmp), is not affected by the "default sample rate" setting, is not resampled in Wine at all, and thus is not affected by this bug. It is affected by a valid bug 25587 in winejack, which existed before the patch and is a separate problem that this patch is not trying to solve.
3. The best quality is obtained when the application output is fed into the hardware buffer of the sound card without any resampling, but this is not always possible.
4. Even when resampling, it is possible to obtain sound quality that is arbitrarily close to the ideal one at frequencies below the half of the lower sample rate, by using a long-enough filter, at the cost of some latency and CPU usage. Duplicating and dropping samples is a fast, very-low-latency, but bad-quality technique of resampling.
5. When the application uses only secondary dsound buffers, wine opens its backend (winealsa.drv or whatever) at the sample rate configured as the "default sample rate" in winecfg.
6. Even when there is only one secondary buffer, wine currently mixes it into primary, possibly with volume and/or sample rate adjustments.
7. The patch by Krzysztof Nikiel implements a windowed-sinc based resampler in wine' dsound mixer.
8. Your words "it is the Linux system mixer need to support all formats and rates when mixing" can be equivalently reformulated "it is a bug that wine itself handles mixing and resampling (including that of secondary dsound buffers into primary) at all".
As for the 24-bit case, well, I am not sure. But the old code also tried to handle it in convert_??_to_24() and convert_24_to_??() functions, so 24-bit secondary buffers at least were meant to work. The new code tries to preserve the existing behaviour. Let's try not to do two things at once (implement both proper resampling and proper subset of supported formats). We can always rip out 24-bit support before or later, as it is a different issue than the zero-order-hold resampler. In other words, I want to see "drop 24-bit support from dsound" and "replace the zero-order-hold internal resampler with something else" as separate patches.