Red Hat Bugzilla – Bug 158571
Scratched sound output
Last modified: 2013-03-13 00:48:22 EDT
Description of problem: Recent esound/alsa/<whatever> produces broken (overdrived??) sound. E.g. | esdplay /usr/share/sounds/KDE_Startup_new.wav | esdplay /usr/share/system-config-soundcard/sound-sample.wav sounds broken. Using the OSS layer sounds fine: | play /usr/share/sounds/KDE_Startup_new.wav Same happens when e.g. playing songs in XMMS; with the esd output plugin they sound broken, while ALSA or OSS output are fine. All this happened after a big system upgrade from FC3.90 to recent rawhide; things were fine before the upgrade. Version-Release number of selected component (if applicable): esound-0.2.35-4 alsa-lib-1.0.9rc2-5 snd_intel8x0 on an ASUS P4C800-E How reproducible: 100%
Disabling 'dmix' in my ~/.asoundrc with | pcm.!default { | type hw | card ICH5 | device 0 | } makes sound work again.
Same report here Also using snd_intel8x0 on an IBM Thinkpad R32. This is probably an ALSA problem. This ~/.asoundrc worked for me. pcm.!default { type hw card 0 device 0 }
The problem can also be solved by download and install esound 0.2.36. I'm not sure whether the problem is caused by esound 0.2.35, or by the patches that fedora applied. Anyway the problem was fixed after applied the above update. I suggest that fedora should treat this problem as critical, as this impact GNOME and all applications that rely on esound.
This is particularly annoying for me with SDL applications (er, games): SDL in FC has been patched to prefer arts, then esound, then oss, then alsa. Now, I run KDE, but cannot use arts because of the delay it introduces to eg. SDL games' sounds. So, I get esound, which produces distorted sound. I "fixed" it for SDL by setting SDL_AUDIODRIVER=alsa ("dsp" works too) in the environment. Anyway, comment 3 seconded, an update would be nice. This is IBM ThinkPad A30p, snd_intel8x0 too. Updating to 0.2.36 fixes it and doesn't appear to break anything (running on FC4). Will attach the patch I used to update.
Created attachment 116716 [details] Update to 0.2.36
I had similar issues and posted a workaround in Comment #2 of Bug #140999.
That workaround doesn't appear to help here, but updating to 0.2.36 does.
Just a further data point: I'm seeing (or hearing!) the same problem on FC4 running on a Dell Latitude D600. The .asoundrc workaround works for me. Haven't tried building my own 0.2.36 package yet.
This affects my motherboard (Gigabyte K8N Pro-SLI with onboard ALC850). Both the solution in comment #2 of this bug and comment #6 worked for me. I also second comment #3.
esound has been 0.2.36 since July, I'm not sure why the bug isn't closed. Am I missing something or are people still seeing this issue in 0.2.36?
FWIW, FC4 is still at 0.2.35, and affected.
Ah, ok. Switching version.
Building 0.2.36-0.fc4.1 as a release candidate. Should be pushed soon.
From User-Agent: XML-RPC esound-0.2.36-0.fc4.1 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
0.2.36-0.fc4.1 seems to fix it here indeed. Thanks!
0.2.36-0.fc4.1 does NOT fix it here. I have left the esd.conf file alone (unlike the suggestion in #140999). I have a Gigabyte K8N Pro-SLI and AMD 64 X2 3800+ (running in non-smp mode due to the numerous problems with the smp kernel). The fix suggested in Comment #2 did fix the problem with the 0.2.35 package. I will reapply it again to see if that fixes it for 0.2.36.
Comment #2 method DID work for me on x86_64. Upgrade to 0.2.36 DID NOT work. Also suggestion on 140999 about forcing a changed sampling rate DID NOT work.
Closing bugs in MODIFIED state from prior Fedora releases. If this bug persists in a current Fedora release (such as Fedora Core 5 or later), please reopen and set the version appropriately.
*** Bug 140999 has been marked as a duplicate of this bug. ***