Here is the patch that addresses the 8 bit mixer problem. I just cut it out of an old development tree that had a lot of other mixer changes so I doubt it will apply cleanly but it will give you an idea of the problem.
This patch and the tests developed for it uncovered the locking issues which I have not fixed yet. I hope to submit a real fix for all this someday but I hope this partial fix can be of some use until then. Robert Reif wrote: > There is a bug in the mixer code that doesn't clear the primary > buffer to a proper silence value for 8 bit hardware buffers. > I have a patch that fixes this that I have been sitting on for months > now. The problem is that there are locking problems in the > SetFormat code for primary buffers that cause it to crash immediately > for the tests I have written to exercise it. I have added some more > locking to try to fix it and it is much better but it's not 100% yet. > It would probably be ok on a single processor system but still has > SMP issues. > > Jerry Jenkins wrote: > > > > sox -c1 -r44100 -sw /usr/share/sounds/pop.wav -tossdsp /dev/audio && > > > wine winamp > > > > > > has the problem, but > > > > > > sox -c1 -r44100 -sb /usr/share/sounds/pop.wav -tossdsp /dev/audio && > > > wine winamp > > > > > > is unbelievably good. How could it be? I should find out if it's > > > something is wrong with my system or something else. > > > > > Only one of my sound cards suffers from the problem when the format of > > primary buffer is 22050 samples per second, 8-bit stereo. The other is > > OK. It appears to be a big challenge for me. And I am a little curious > > about how many peoples would have such experience. > > I submitted a new patch, please test it.
dsound.diff
Description: application/unknown-content-type-diff_auto_file
