[Bug 14717] resampled sound is horrible

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=14717

--- Comment #72 from Alexander E. Patrakov <patrakov at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.