http://bugs.winehq.org/show_bug.cgi?id=14717
--- Comment #78 from Raymond superquad.vortex2@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?
- 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
- 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
- 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
- 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
- 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
- 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