[Bug 14717] resampled sound is horrible

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Dec 26 20:15:00 CST 2010


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

--- Comment #78 from Raymond <superquad.vortex2 at gmail.com> 2010-12-26 20:14:59 CST ---
(In reply to comment #72)
> 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.

win98 did not has any kmixer

The current implementation of wineoss and winealsa is a trimmed down version of
vxd driver which provide software mixing in dsound and winealsa.drv still does
not provide access to secondary hardware buffers of those hardware mixing sound
cards

THis mean that it does not support multiple waveoutopen bug#22880 


Kmixer just set dwHwMixingBuffers,.... in DSCAPS so that dsound applications
believe that all supported sound cards have hardware secondary buffers 


> 
> 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.

yes , waveoutopen in winealsa.drv use the "default" device which you can
override to use "hw" directly, dmix or pulse ( in the past, wine use default:x
to use the default playback device of the sound card x )

>> 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.

it is winejack incorrectly informed foobar that the it can support 44100Hz but
you start jack server to run at 48000Hz, the only way is to use foobar's
resampler or you add a resampler inside winejack.

or winejack can stop the jack server and restart the jack server at the
application's requested sample rate

adding a cpu intensive resampler in dsound is a nightmare unless you implement
an option to allow user to select the quality of SRC in winecfg. 

the default SRC quality should be the one with minimum CPU usage 

some windows drivers allow you to select the quality of the SRC instead of the
sampling rate

> 
> 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.

Some professional users are looking for bit exact, no mixing , up-sampling or
down sampling when listing music (i.e. no format conversion ) and it need the
sound card support the sampling rate of the audio stream

> 
> 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.

No, winejack does not support dsound, 

you can only use one of the wine audio driver at a time.

The checkbox in winecfg mislead the user to believe that they can use any of
them at the same time, but in fact wine only use the first checked driver in
the list

winecfg should use radio button instead of checkbox to select audio driver

> 
> 6. Even when there is only one secondary buffer, wine currently mixes it into
> primary, possibly with volume and/or sample rate adjustments.

Yes, but there is no volume gain/atten when mixing done 
you should notice about those "FIXME: SetVolumePan" messages in the log


> 
> 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".
> 

No, because none of those linux system mixer can support all sound cards, wine
have to provide a fallback in "emulation" mode to provide mixing for those
sound cards 

/dev/dsp does not support mixing for most of the sound cards
so wineoss also need dsound to perform software mixing

snd-emu10k1 must use "front" device for playback since there is a hook to
change the internal routing to different jacks and this is why wineoss suddenly
fail to work with SB live! sound cards when using ALSA 's OSS emulation

> 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.

I think the problem is jack server only support float format , winejack must
provide 16bits to float conversion inside winejack for waveoutopen

As winejack does not really provide dsound support ( no DSCAPS ) in wine,

I have doubt about adding 24bits support to dsound when your test case is using
winejack and especially foobar is not an dsound game application

-- 
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.



More information about the wine-bugs mailing list