Description of problem: Since upgrading to kernel 2.6.34, audio has been unusable on my EMU101kX-based sound card. Playback from MythTV, Audacious and Totem, all exhibit severe audio defects -- when using PulseAudio, it sounds as if they are in fast-forward; when going to ALSA directly, playback runs extremely slow, with large gaps between short snippets of audio. Version-Release number of selected component (if applicable): - kernel-2.6.34.6-54.fc13.i686 AND kernel-2.6.34.6-47.fc13.i686 - pulseaudio-0.9.21-6.fc13.i686 - alsa-lib-1.0.23-1.fc13.i686 Additional information: I have had problems with this device in the past (see bug #505010, for example), but for the last 10 months it's been working fine. The problems have only come up in the kernel versions mentioned above. PulseAudio-related syslog messages generated while running MythTV: Sep 12 22:54:38 beren pulseaudio[4883]: ratelimit.c: 21 events suppressed Sep 12 22:54:43 beren pulseaudio[4883]: ratelimit.c: 106 events suppressed Sep 12 22:54:48 beren pulseaudio[4883]: ratelimit.c: 103 events suppressed Sep 12 22:54:53 beren pulseaudio[4883]: ratelimit.c: 102 events suppressed Sep 12 22:54:58 beren pulseaudio[4883]: ratelimit.c: 106 events suppressed Sep 12 22:55:03 beren pulseaudio[4883]: ratelimit.c: 104 events suppressed Sep 12 22:55:08 beren pulseaudio[4883]: ratelimit.c: 104 events suppressed Sep 12 22:55:13 beren pulseaudio[4883]: ratelimit.c: 108 events suppressed Sep 12 22:55:18 beren pulseaudio[4883]: ratelimit.c: 102 events suppressed Sep 12 22:55:23 beren pulseaudio[4883]: ratelimit.c: 106 events suppressed Sep 12 22:55:24 beren pulseaudio[4883]: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Sep 12 22:55:24 beren pulseaudio[4883]: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_emu10k1x'. Please report this issue to the ALSA developers. Sep 12 22:55:24 beren pulseaudio[4883]: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Sep 12 22:55:28 beren pulseaudio[4883]: ratelimit.c: 110 events suppressed
A similar bug was fixed in emu10k1 but emu10k1x did not get a fix: https://bugzilla.kernel.org/show_bug.cgi?id=16300 The emu10k1 fix went to -stable and is in 2.6.34.6 but it won't help emu10k1x.
I have just encountered the same problem. System: Dell Dimension 4550, Pentium 4 O/S Fedora 13: 2.6.34.7-61.fc13.i686.PAE Sound Card: SoundBlaster live! value, model SB0200. I note that this sound card has a bespoke connector to couple audio signals to the front of the computer case, so is it an OEM for Dell? lspci gives EMU10k1X I got the response when I ran the system up using a live Fedora 14 CD.
Use value 11 for xrun_debug and attach a log with some comments where the problem occurs: http://www.alsa-project.org/main/index.php/XRUN_Debug
Jaroslav, I've read the alsa link, and as su, issued the command echo 11 > /proc/asound/card0/pcm0p/xrun_debug However, being new to this, I am at a loss where to look for the log output you ask for. Can you advise a newbie please?
The kernel log is in /var/log/messages .
Jaroslav, Thank you for the advice. annotated log: (invoking twice the 'test loudspeakers' option in the system preferences sound menu) Nov 25 13:25:16 Deep-thought pulseaudio[1629]: ratelimit.c: 67 events suppressed Nov 25 13:25:21 Deep-thought pulseaudio[1629]: ratelimit.c: 107 events suppressed Nov 25 13:25:26 Deep-thought pulseaudio[1629]: ratelimit.c: 105 events suppressed (playing an Audio CD using Rhythmbox Music Player) Nov 25 13:26:15 Deep-thought pulseaudio[1629]: ratelimit.c: 31 events suppressed Nov 25 13:26:20 Deep-thought pulseaudio[1629]: ratelimit.c: 108 events suppressed Nov 25 13:26:25 Deep-thought pulseaudio[1629]: ratelimit.c: 105 events suppressed Nov 25 13:26:30 Deep-thought pulseaudio[1629]: ratelimit.c: 106 events suppressed In both cases the audio sounded as if it was being played at approx twice speed.
Jaroslav, A further investigation on my part: I have run the same Pentium 4 machine with the following versions of Fedora 13: For 2.6.33.3-85.fc13.i686.PAE and 2.6.33.6-147.fc13.i686 the sound works correctly. For 2.6.34.7-56.fc13.i686.PAE and 2.6.34.7-61.fc13.PAE the sound does NOT work correctly, as reported earlier.
For the last few weeks I have been running Fedora's kernel-2.6.35.6-48 with http://git.kernel.org/linus/7b3a177b0d4f92b3431b8dca777313a07533a710 reverted. I can report that my audio has no problems at all with this commit reverted.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Yes, this bug still exists as of kernel-2.6.35.13-91.fc14.i686. As mentioned in comment 8, reverting commit 7b3a177b makes the problem go away. I have been needing to patch every Fedora kernel since last November in order to have usable audio.
Until we have some logs from comment#3 , we cannot look what's wrong with your hw. Reverting patch in comment#8 is just a workaround which is not acceptable for all soundcards.
Created attachment 502272 [details] echo 27 > xrun_debug
Created attachment 502274 [details] echo 31 > xrun_debug These logs were generated on kernel-2.6.35.13-91.fc14.i686, with xrun_debug set to 27 and 31 respectively. The jiffies check appears to work around the audio problem. Please let me know if there are any other logs you require.
This bug is NOT present on kernel-2.6.38.8-32.fc15.i686 .