http://bugs.winehq.org/show_bug.cgi?id=14717
--- Comment #236 from Andrew Eikum aeikum@codeweavers.com 2011-11-11 08:37:08 CST --- (In reply to comment #225)
If most of the improvements actually come from moving the old bad resampler to the mixer thread, then I suggest that Wine developers merge the first patch in my series, and then we can discuss the rest of the patches separately, so that the two types of issues are not mixed together.
Well, your resampler improvements depend on moving resampling back to the mixer thread, and if that causes regressions, then your improvements are blocked. So we're trying to fix these regressions so your fixes can get in. I guess we could move the discussion to Bug 9612, but I don't really see any reason to.
(In reply to comment #227)
P.S. Sorry for hi-jacking the bug report a bit more but I have a semi-related question for Andrew to ask: looks like that the default samplerate for dsound is set to be 44100Hz, which differs from the typical 48000Hz value that's being used by most AC97 codecs.
Maybe it would be wise to change the default to be 48KHz?
I don't have a problem with that. If you can provide some evidence that most cards use that rate (or some multiple), it will help getting through the wine-patches submission process.
(In reply to comment #228)
CPU usage is quite high (over 20%) for vlc especially when user mis-configure default sample rate to 96000Hz when the sound card only support 48000Hz
when normal usage is only 1% for vlc for playing 16bit 44100Hz
I think I will add options for different resampler qualities (see comment 230) so users can tweak this down when they need to.
(In reply to comment #231)
What can be done, though, is to disable the ALSA resampler (only if called from DirectSound! that's important!), ask ALSA for approximately the default sample rate, and use the result. Something like this pseudocode (copied from MPlayer that gets the logic right, but untested in my own code):
I wonder if a better solution is to have dsound use the sample rate reported by GetMixFormat() as its default primary buffer rate. Then the drivers could be improved to report the device's preferred sample rate, if they don't already.
(In reply to comment #232)
Sure, that's why I had been a bit pissed off then default sample rate setting had been removed from winecfg.
Part of the problem with Wine's audio situation was the plethora of different configuration options that were readily available to users. When a bug report comes in, nobody remembers which combinations of settings resulted in which end result, so they file conflicting or incorrect reports. Requiring the user to go through the registry to tweak options means they're less likely to mess with the defaults and create bogus reports. And if someone _does_ go through the effort, they're more likely to either remember it, or actually understand what they're doing.
I'm sorry it's not as convenient as it used to be, but I felt that consistent, sane bug reports were worth the cost. As the audio situation starts settling down, we can re-evaluate which options are worth having handy access to and perhaps add a couple back to the Audio tab.