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.
Hello Jerry,
Saturday, October 4, 2003, 11:56:11 AM, you wrote:
JJ> Only one of my sound cards suffers from the problem when the format of JJ> primary buffer is 22050 samples per second, 8-bit stereo. What's the soundcard ?
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.
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.
Robert Reif wrote:
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.
Seems there are too few EnterCriticalSections to make things better. Hope you can complete it soon.
I guess that adding critical sections can synchronize DSOUND, but the sound driver - playing thread - remains unchanged, it still goes its own way:-(.
Robert Reif wrote:
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.
Seems there are too few EnterCriticalSections to make things better. Hope you can complete it soon.
I guess that adding critical sections can synchronize DSOUND, but the sound driver - playing thread - remains unchanged, it still goes its own way:-(.
Sorry, here is the missing text.
What will happen if the driver access the data we are going to clean or mix? I wish it would never take place.
-
Jerry Jenkins -
Oleg Prokhorov -
Robert Reif