[Bug 14717] resampled sound is horrible

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

--- Comment #74 from Alexander E. Patrakov  2010-12-26 05:31:46 CST ---
(In reply to comment #73)
> if you have visited foobar2k forum, those users prefer foo_out_asio or
> foo_out_ks which bypass kmixer
>
> dsound is designed for game , the cpu usage and latency is more important when
> mixing sound effects

Have you looked at the patch? At the lowest quality setting ("fast"), the
additional latency is 4 samples, and for the "slow" setting, it is 28 samples.
This is still less than 1 ms. Compare this to the documented 10ms write lead
that both Windows and wine apply to secondary buffers - I think that in Windows
this delay is introduced specifically to allow for resampling.
> if your aim is to get best quantity of music in wine , use winealsa and change
> the default device to bypass any mixer ( dmix , pulseaudio, jack ... )

This works well for WaveOut apps only. For DirectSound-based apps, this works
only when the "default sample rate" setting in winecfg is the same as the
actual sample rate used by the application for secondary buffers. Obviously,
this is not good when there are files with different sample rates (i.e., some
ripped from CD and some from DVD) in the playlist.

Proof: use winealsa, change the default device to be "hw:0" (in .asoundrc:
pcm.!default "hw:0"), play some files with different parameters in foobar2000,
see (cat /proc/asound/card0/pcm0p/sub0/hw_params) that Wine always opens the
device with the "default sample rate" - i.e. resamples.
> just use a better resampler instead of using alsa's default resampler
>
> http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=doc/samplerate.txt
>
> http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=doc/speexrate.txt

Yes, I know about these documents. The default ALSA resampler is settable with
the "defaults.pcm.rate_converter" variable in .asoundrc. And these resamplers
are good! The whole problem is that wine forces the use of its own bad
resampler instead of a resampler from ALSA when an application requests a
secondary DirectSound buffer with a rate different from the default sample rate
configured in winecfg, and the patch attempts to replace this bad resampler
with a better one.
> pcm.!default {
>         type rate
>         slave {
>                 pcm "hw:0,0"
>                 rate 48000
>         }
>         converter "xxxx"    
> }

Yes, that's equivalent to what I wrote. And it suffers from the same problem:
wine forces the use of its own sample-duplicating-and-dropping resampler
(equivalent to "samplerate-order") for DirectSound apps before the ALSA
resampler can see the data.