GNOME Bugzilla – Bug 98538
causes a tinny sound sometimes when using alsa
Last modified: 2007-01-07 15:14:42 UTC
At times when a sound is played through esound (currently only sawfish via esdplay and gaim via native esd support) any currently playing sound (ie.. xmms playing through OSS or ALSA output plugin, or Unreal tournament 2003, etc..) the sound will go "tinny" when esound opens the oss dsp device and plays a sound. and will stay like that for quite a while, or if I cause the window manager or something to play a bunch more sounds via esd it will restore the "normal" sound quicker.. I'm running Redhat 7.2 kernel 2.4.9-34. I have a soundblaster Live card. I'm using Alsa 0.9.0rc5 (does the same under rc3) And using an OSS compiled esound (2.28 ximian RPM). Also tried the esound 2.29 source RPM from Mandrake 9.0 recompiled on my system. I tried compiling the 2.29 source with alsa support but I got NO sound output. I will try and see if I can "capture" and record a sample of this occurance and attach it..
Created attachment 12308 [details] Ogg compressed audio capture of the sound on my computer..
I don't have any problem on my SB Live with emu10k1 driver version 0.20 (Jan 4 2003) or with alsa 0.9.0rc8a. Since sound output is corrupted when /dev/dsp is opened, it seems to not be a bug in esound, but a bug in the version of your sound driver. Closing as NOTGNOME.. Reopen if you have you find more info which would incriminate esound..
After more verification, this bug doesn't seems to be related on the fact the sound card is already playing something else.. To reproduce this bug more easily : run gnome-sound-properties choose a sound to play and press "Play" button If you press it several times faster, it will play ok.. But if you press it one time, wait 2 s, press again, you can hear the sound on a very soft tone.. Reopening
*** Bug 103248 has been marked as a duplicate of this bug. ***
Back again.. I get the same behaviour (sound very low, causing event to become almost unhearable) using direct play to the sound card.. But only with VERY small sample.. This is not a esound bug, but an sound driver bug..
Are you sure?? What did you do to recreate the problem w/o esound?? I'll try it on my system as well.. I have gone now as far as plainly disabline esound.. (esdctl off) on my system as this problem ONLY happens when esound is active.. And it has only been caused by esound playing sounds on my system... At first I thought it might have been a load issue, but now that I have a sytem that's 3 times as fast, it still occurs..
I use "play" from sox package, on the same file GNOME is using for events.. and I got the same result (volume changed, etc..)
Any news on this issue?
still happens when I use the OSS ouput with alsa 0.9.6... I recompiles the latest esound with alsa support and am currently going direct to ALSA, and haven't been having the problems.. It still currently is the only application that has given me this problem.. I'm downloading the latest alsa (0.9.8), and will report if the problem still exists on that versin.
Reopening. Still happening I guess?
Yes, it's still a problem. It appears to be caused by sending only partial buffers to the sound card -- somewhere (either in esound or in the sound driver), the last few frames from one button sound get stuck, and eventually get played when the next button sound is played. It's pretty obvious if you are playing button sounds that end abruptly instead of fade out.
I have not had this occuring in *current* Fedora distributions. Can this be closed??
If it's not happening any more I guess we should close it yes.