http://bugs.winehq.org/show_bug.cgi?id=19124
Raymond superquad.vortex2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2@gmail.com
--- Comment #12 from Raymond superquad.vortex2@gmail.com 2010-09-26 22:36:07 CDT --- (In reply to comment #10)
I don't know where the bad format comes from. However, it's also a Wine bug: Native refuses the bad format (alas I never got along to writing testcases as you suggested in comment #5, the MCI keeps me busy enough) and stays in (or recovers) a working state while Wine breaks havoc. Bug #16834 is another case where error paths in dsound cause it to become internally inconsistent.
this bug can be easily reproduced when using "hw" device (i.e. set registry "UseDirectHW" to "Y" with "dsound_test dsound" when your sound card does not support mono or 11025Hz or 22050Hz
The current implemenation of SetFormat() function of winealsa.drv is unable to set the buffer to the closest supported format
1) most of those hardware mixing sound cards support 8bit or 16bit, when the application requested for 32bit , winealsa.drv does not set the format to the closest format - 16bit
2) Most of the onboard sound card does not support mono or 8bits, when the application request for mono, winealsa.drv does not set the format to the closest format - stereo or 16 bits
The major reason is winealsa.drv does not set the dwFlags of DSCAPS according to the hardware capability of the sound card , it just assume all the sound card use "plug" plugin to provide all the conversion