I've noticed following things in logfile: # grep pulseaudio /var/log/messages Feb 15 18:22:29 sandworm pulseaudio[19255]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. Feb 15 18:51:36 sandworm pulseaudio[19255]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. Feb 15 19:33:32 sandworm pulseaudio[19255]: module-alsa-sink.c: Increasing wakeup watermark to 354,01 ms Feb 15 19:35:15 sandworm pulseaudio[19255]: module-alsa-sink.c: Increasing wakeup watermark to 368,53 ms Feb 15 19:58:21 sandworm pulseaudio[19255]: module-alsa-sink.c: Increasing wakeup watermark to 34,01 ms Feb 15 20:00:02 sandworm pulseaudio[19255]: module-alsa-sink.c: Increasing wakeup watermark to 68,03 ms Feb 15 20:00:28 sandworm pulseaudio[19255]: module-alsa-sink.c: Increasing wakeup watermark to 136,05 ms Feb 15 20:20:09 sandworm pulseaudio[19255]: module-alsa-sink.c: Increasing wakeup watermark to 272,11 ms Feb 15 21:22:51 sandworm pulseaudio[19255]: module-alsa-sink.c: Increasing wakeup watermark to 368,53 ms Feb 15 21:51:29 sandworm pulseaudio[19255]: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 18446744073709551584 bytes (418293516410 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. (PA crashed here? no info in logs) Feb 15 22:13:05 sandworm pulseaudio[27727]: pid.c: Stale PID file, overwriting. Feb 15 22:13:05 sandworm pulseaudio[27727]: alsa-util.c: Cannot find fallback mixer control "Mic". Feb 15 22:21:16 sandworm pulseaudio[27727]: module-alsa-sink.c: Increasing wakeup watermark to 40,00 ms Feb 15 22:25:57 sandworm pulseaudio[27727]: module-alsa-sink.c: Increasing wakeup watermark to 80,00 ms Feb 15 23:23:02 sandworm pulseaudio[27727]: module-alsa-sink.c: Increasing wakeup watermark to 160,00 ms Feb 15 23:48:43 sandworm pulseaudio[27727]: module-alsa-sink.c: Increasing wakeup watermark to 34,01 ms This is during typical usage -- half an hour of watching movie in Totem, then occasional IM ding played by "paplay". HW is Intel HDA from Centrino 2 in Thinkpad T400 laptop. # lspci | grep -i audio 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) Linux sandworm.fordon.pl.eu.org 2.6.28.1-11.fc10.x86_64 #1 SMP Mon Jan 19 02:02:10 EST 2009 x86_64 x86_64 x86_64 GNU/Linux pulseaudio-0.9.14-1.fc10.x86_64 rest of packages up-to-date with propsed-updates for f10.
This is an alsa kernel driver bug. Reassigning.
I took the liberty to make this an F11Blocker given that this makes PA fail sooner or later and intel-hda cards are the most common cards available. If this bug isn't fixed audio will not work for a majority of people.
*** Bug 483559 has been marked as a duplicate of this bug. ***
Lennart, whats the status of getting Takashis hda fixes into the rawhide kernel ?
That patch is now in the rawhide kernel. It needs to be investigated whether all problems on HDA are now fixed.
This patch actually made my experience worse. Now pulseaudio "dies" after a short while. See bug #492698 for more info.
Hmm, I guess that means those issues are not fixed, then.
*** Bug 492698 has been marked as a duplicate of this bug. ***
Got this behavior on every intel-hda machine I've tested so far; at least it's reliable and the error message is pretty clear. kernel-PAE-2.6.29-16.fc11.i686 alsa-plugins-pulseaudio-1.0.18-3.fc11.i586 alsa-lib-1.0.19-3.fc11.i586 pulseaudio-0.9.15-3.test5.fc11.i586
Jeff, this bug is about intel-hda, not intel8x0. Please don't add noise to this bug report by pasting unrelated stuff!
(In reply to comment #11) > Jeff, this bug is about intel-hda, not intel8x0. Please don't add noise to this > bug report by pasting unrelated stuff! it would be nice to mention bug 472339 and not just kick out poor reporter.
Btw, Jaroslav, the big issue here is this one: Feb 15 21:51:29 sandworm pulseaudio[19255]: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 18446744073709551584 bytes (418293516410 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. The issue about POLLOUT is also existant but not as fatal as this snd_pcm_avail() issue. Also, one thing: at all the occurances of this issue adjusting the return value by 2^64 (on x86-64) or 2^32 (on x86) makes the return values of snd_pcm_avail() much more sensible. For example, in the line shown above 2^64-18446744073709551584 is 32. Which kinda would make sense as return value for snd_pcm_avail(). Thus I am tempted to suggest that this is a simple overflow in the ALSA code somewhere. (Please note that for presentation purposes PA converts the return value of snd_pcm_avail() from samples into bytes. But that's only done for presentation.)
Please, try to reproduce with aplay ring buffer position tests (to eliminate PA) - see bug#472339. Also, please, Lennart, add snd_pcm_dump() - probably redirected to a file - to your code when snd_pcm_avail_update() fails. I just added some more debug info to the pcm_hw plugin to provide better orientation where the bug might be. This code will be in alsa-lib 1.0.20 which I plan to release soon. POLLOUT - which configuration (snd_pcm_dump()) is used? In some cases (like dmix), the process might be woken up just for updating of internal status of alsa-lib plugins. It's in the current documentation for *revents(). Also, snd_pcm_dump() output might help to identify the runtime situation for this problem.
Jaroslav, I will modify PA to include snd_pcm_dump() along with those warnings. Should hit rawhide tonight. Regarding POLLOUT: PA avoidss dmix. We open the devices as 'front:x', 'surround40:x', 'surround41:x', 'hdmi:x', 'iec985:x', and 'hw:'x (for mono devices). We do not open 'default:x' nor 'dmix:' or any other higher-level module. On some cards 'multi:' might be used for the 'surround:x' modules. I don't have a snd_pcm_dump() output handy for the POLLOUT cases. I'll add that when I hit the bug again. It is ok for being woken up for cases like you suggest, however revents as returned by snd_pcm_poll_descriptors_revents() should not claim that we could write something in that case. i.e. POLLOUT should still be off! It would be completely fine if revents would return 0 in that case. But triggering POLLOUT and then having snd_pcm_avail() = 0 is a bug I would say.
Thanks Lennart. The wrong POLLOUT wakeup might be related to snd_pcm_avail() issues. Your code is OK in PA. I'll look to this issue later. I intensively tested PA and other debug mechanisms on my relatively slow EeeBox B202 based on Atom N270 and ICH7-M chipset and I prepared two patches which may solve or help to debug this issue: http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=fa00e046b41663cbda9b1affc0594669e5f14219 http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=bbf6ad1399e9516b0a95de3ad58ffbaed670e4cc Please, if you report any trouble, enable the xrun_debug checks for playback (and maybe also for capture) streams: echo 1 > /proc/asound/card0/pcm0p/xrun_debug echo 1 > /proc/asound/card0/pcm0c/xrun_debug or for all PCM devices: for i in `find /proc/asound/card0 -name xrun_debug` ; do echo 1 > $i; done Look to /var/log/messages or use dmesg to see kernel messages.
*** Bug 488025 has been marked as a duplicate of this bug. ***
Using the second patch from comment #16 (first didn't apply cleanly to fedora kernel-2.6.29.1-66.fc11), my intel-hda system seems to have stopped returning silly values from snd_pcm_avail() (i.e. no more pulseaudio crashes) I do see these messages in dmesg, though: intel8x0_measure_ac97_clock: measured 50785 usecs intel8x0: measured clock 216 rejected intel8x0: clocking to 48000 [...] ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=8192, delta=8193, period=16384, jdelta=0/185) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=8192, delta=8193, period=16384, jdelta=0/185) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=8192, delta=8194, period=16384, jdelta=0/185) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=8192, delta=8193, period=16384, jdelta=0/185) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=0, delta=8195, period=16384, jdelta=0/185) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=0, delta=8318, period=16384, jdelta=2/188) ALSA sound/core/pcm_lib.c:337: hda_codec: hw_ptr skipping! (pos=8192, delta=8193, period=16384, jdelta=0/185) jdelta never exceeded 19 in my testing (playing multiple audio streams, messing with flash video, etc.) and I didn't experience noticeable skips. Would be nice to get a rawhide kernel build (or a scratch build) with both of these patches to see if other people can confirm the fix.
These patches (and others from alsa-kernel) will be in 2.6.29.1-70, which should appear in tomorrow's rawhide. Can the reporter(s) in this bug please retest with that kernel and report whether it works or not?
I haven't had a pulseaudio crash since using these patches.
I've been informed that these patches have gone into the new F10 kernel in updates-testing: * Mon Apr 13 2009 Chuck Ebbert <cebbert> 2.6.29.1-22 - Copy ALSA pulseaudio fixes from F-11. See https://admin.fedoraproject.org/updates/F10/FEDORA-2009-3685 F10 users, please update to kernel-2.6.29.1-30.fc10 and retest.
Anyone who has experienced the snd_pcm_avail() overflow (and associated PulseAudio crashes) on intel-hda sound hardware, please update your kernel: F11: kernel-2.6.29.1-70.fc11 or newer F10: kernel-2.6.29.1-30.fc10 or newer and retest. I haven't been able to reproduce the snd_pcm_avail() problem while using these kernels. Tomasz, since you're the original reporter, I'd like to make sure this works for you. Unless someone can reproduce the problem I think this bug is fixed.
Will, during last 3 days I haven't observed overflow. This bug appears to be fixed, thanks for hard work.
Uhm, right... Apr 16 23:24:27 sandworm pulseaudio[18473]: alsa-sink.c: Increasing minimal latency to 1,00 ms Apr 16 23:24:27 sandworm pulseaudio[18473]: alsa-sink.c: Increasing minimal latency to 2,00 ms Apr 16 23:24:28 sandworm pulseaudio[18473]: alsa-sink.c: Increasing minimal latency to 4,00 ms Apr 16 23:24:30 sandworm pulseaudio[18473]: alsa-sink.c: Increasing minimal latency to 8,00 ms Apr 16 23:24:31 sandworm pulseaudio[18473]: alsa-sink.c: Increasing minimal latency to 16,00 ms Apr 16 23:24:32 sandworm pulseaudio[18473]: alsa-sink.c: Increasing minimal latency to 26,00 ms Apr 16 23:24:37 sandworm pulseaudio[18473]: alsa-sink.c: Increasing wakeup watermark to 15,99 ms Apr 16 23:24:40 sandworm pulseaudio[18473]: alsa-sink.c: Increasing minimal latency to 36,00 ms Apr 16 23:24:40 sandworm pulseaudio[18473]: alsa-source.c: Increasing minimal latency to 1,00 ms Apr 16 23:24:40 sandworm pulseaudio[18473]: alsa-sink.c: Increasing wakeup watermark to 25,99 ms Apr 16 23:24:40 sandworm pulseaudio[18473]: alsa-source.c: Increasing minimal latency to 2,00 ms Apr 16 23:24:42 sandworm pulseaudio[18473]: source-output.c: Assertion 'pa_frame_aligned(chunk->length, &o->source->sample_spec)' failed at pulsecore/source-output.c:429, function pa_source_output_push(). Aborting.
Okay, but that's not snd_pcm_avail() overflowing. File a new bug, please? Be sure to include kernel and pulseaudio version numbers.
Tomasz: that issue seems to be related to the tunnel modules. Have you been using those? This is unrelated to ALSA HDA. There's already a bug for the tunnel issue.
I have tunnel modules loaded but not using them, as sound is very choppy and leads to PA crash (see bug#496310). I have not seen snd_pcm_avail() crash in last few days (after installing -70 kernel).
*** Bug 497319 has been marked as a duplicate of this bug. ***
kernel-2.6.29.2-52.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.2-52.fc10
even with 2.6.29.29.2-53 still no sound for me: I: caps.c: Limited capabilities successfully to CAP_SYS_NICE. I: caps.c: Dropping root privileges. I: caps.c: Limited capabilities successfully to CAP_SYS_NICE. W: pid.c: Stale PID file, overwriting. W: alsa-util.c: Device hw:2 doesn't support 44100 Hz, changed to 48000 Hz. W: alsa-util.c: Cannot find fallback mixer control "Mic". W: alsa-util.c: Device hw:0 doesn't support 44100 Hz, changed to 16000 Hz. W: alsa-util.c: Device hw:0 doesn't support 2 channels, changed to 1. W: module-alsa-source.c: Your kernel driver is broken: it reports a volume range from 5.00 dB to 5.00 dB which makes no sense. E: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 18446744073709486080 bytes (384307167860 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers. N: module-alsa-source.c: Increasing wakeup watermark to 36.75 ms Soft CPU time limit exhausted, terminating. Hard CPU time limit exhausted, terminating forcibly. Aborted Hardware is: 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
(In reply to comment #30) > even with 2.6.29.29.2-53 still no sound for me: Sorry, i mean 2.6.29.2-52 of course.
I did tests with kernel-2.6.29.1-42.fc10, No sound at all. Hardware (notebook HP dv5): 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) /var/log/messages Apr 29 18:49:32 pavilon kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 Apr 29 18:49:32 pavilon kernel: input: HDA Intel Mic at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/input/input13 Apr 29 18:49:32 pavilon kernel: input: HDA Intel Mic at Sep UNKNOWN Jack as /devices/pci0000:00/0000:00:1b.0/input/input14 Apr 29 18:49:32 pavilon kernel: input: HDA Intel HP Out at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/input/input15 ... Apr 29 18:51:44 pavilon pulseaudio[17077]: module-alsa-sink.c: Increasing wakeup watermark to 40.00 ms
Re-tested with kernel 2.6.29.2-52. Still no sound. /var/log/messages Apr 29 19:25:55 pavilon kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 Apr 29 19:25:55 pavilon kernel: input: HDA Intel Mic at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/input/input13 Apr 29 19:25:55 pavilon kernel: input: HDA Intel Mic at Sep UNKNOWN Jack as /devices/pci0000:00/0000:00:1b.0/input/input14 Apr 29 19:25:55 pavilon kernel: input: HDA Intel HP Out at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/input/input15 Apr 29 19:25:55 pavilon kernel: platform microcode: firmware: requesting intel-ucode/06-17-06 Apr 29 19:25:55 pavilon kernel: platform microcode: firmware: requesting intel-ucode/06-17-06 [root@pavilon ~]# tail --lines=500 /var/log/messages | grep -i audio Apr 29 19:26:02 pavilon bluetoothd[16682]: Parsing /etc/bluetooth/audio.conf failed: No such file or directory Apr 29 19:29:44 pavilon pulseaudio[17124]: module-alsa-sink.c: Increasing wakeup watermark to 40.00 ms
(In reply to comment #32) > I did tests with kernel-2.6.29.1-42.fc10, > No sound at all. I don't see any message like "snd_pcm_avail_update() returned a value that is exceptionally large" in your logs. You probably have a different problem - likely the volume control for your card is set too low. Please see http://forums.fedoraforum.org/showpost.php?p=1206905&postcount=14 for information about fixing your volume control.
Yes, you are right Will, I filled new bug report https://bugzilla.redhat.com/show_bug.cgi?id=498289 So this bug seems to be fixed then.
(In reply to comment #30) > even with [2.6.29.2-52] still no sound for me: > > W: module-alsa-source.c: Your kernel driver is broken: it reports a volume > range from 5.00 dB to 5.00 dB which makes no sense. > E: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally > large: 18446744073709486080 bytes (384307167860 ms) Most likely this is an ALSA > driver bug. Please report this issue to the PulseAudio developers. > N: module-alsa-source.c: Increasing wakeup watermark to 36.75 ms > Soft CPU time limit exhausted, terminating. > Hard CPU time limit exhausted, terminating forcibly. > Aborted Hrm. But you aren't hitting the assert() in pulseaudio. What pulseaudio version are you running? and what does 'lsmod | grep snd-' say? Are you sure you're running the 2.6.29.2-52 kernel?
I have the following environment: $ uname -a Linux localhost.localdomain 2.6.29.2-52.fc10.x86_64 #1 SMP Mon Apr 27 16:00:44 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux $ lsmod | grep snd snd_hda_codec_analog 76336 1 snd_hda_intel 28840 3 snd_hda_codec 63424 2 snd_hda_codec_analog,snd_hda_intel snd_seq_dummy 3108 0 snd_seq_oss 31424 0 snd_seq_midi_event 6656 1 snd_seq_oss snd_seq 54032 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_pcm_oss 43344 1 snd_mixer_oss 15216 2 snd_pcm_oss snd_usb_audio 93712 0 snd_usb_lib 16688 1 snd_usb_audio snd_pcm 78184 5 saa7134_alsa,snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_usb_audio snd_rawmidi 22608 1 snd_usb_lib snd_seq_device 7060 4 snd_seq_dummy,snd_seq_oss,snd_seq,snd_rawmidi snd_hwdep 8296 2 snd_hda_codec,snd_usb_audio snd_timer 22160 2 snd_seq,snd_pcm snd 63464 18 saa7134_alsa,snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_seq_dummy,snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_usb_audio,snd_usb_lib,snd_pcm,snd_rawmidi,snd_seq_device,snd_hwdep,snd_timer snd_page_alloc 8976 2 snd_hda_intel,snd_pcm soundcore 6800 3 snd $ rpm -qa| grep pulseaudio pulseaudio-core-libs-0.9.14-1.fc10.x86_64 pulseaudio-libs-0.9.14-1.fc10.x86_64 pulseaudio-utils-0.9.14-1.fc10.x86_64 pulseaudio-module-x11-0.9.14-1.fc10.x86_64 pulseaudio-module-zeroconf-0.9.14-1.fc10.x86_64 pulseaudio-module-jack-0.9.14-1.fc10.x86_64 xine-lib-pulseaudio-1.1.16.3-2.fc10.x86_64 pulseaudio-libs-devel-0.9.14-1.fc10.x86_64 alsa-plugins-pulseaudio-1.0.18-2.fc10.x86_64 pulseaudio-libs-zeroconf-0.9.14-1.fc10.x86_64 pulseaudio-module-gconf-0.9.14-1.fc10.x86_64 pulseaudio-module-bluetooth-0.9.14-1.fc10.x86_64 pulseaudio-libs-glib2-0.9.14-1.fc10.x86_64 pulseaudio-module-lirc-0.9.14-1.fc10.x86_64 pulseaudio-esound-compat-0.9.14-1.fc10.x86_64 pulseaudio-0.9.14-1.fc10.x86_64
kernel-2.6.29.2-52.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4132
This bug is an F10 bug, and the F11 behavior seems to be better, so I'm dropping this from F11Blocker.
kernel-2.6.29.3-60.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.3-60.fc10,hal-0.5.12-15.20081027git.fc10
With 2.6.29.3-60.fc10.x86_64 i'm still hitting this and PA dies: "E: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 18446744073709486080 bytes (384307167860 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers."
kernel-2.6.29.3-60.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4818
(In reply to comment #41) > With 2.6.29.3-60.fc10.x86_64 i'm still hitting this and PA dies: > > "E: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally > large: 18446744073709486080 bytes (384307167860 ms) Most likely this is an ALSA > driver bug. Please report this issue to the PulseAudio developers." Please, enable xrun debugging driver - see comment#16 - and look to 'dmesg' output what goes wrong. But value 18446744073709486080 is suspicious - its a negative value ffffffffffff0000 in hex. It looks like another value wraping problem in PA (missing negative value check?). Lennart?
> But value 18446744073709486080 is suspicious - its a negative value > ffffffffffff0000 in hex. It looks like another value wraping problem in PA > (missing negative value check?). Lennart? I am pretty sure this is not PA's fault. This is the code in question: http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/alsa-util.c;h=75b84c401dfbdd75ba9c7e91d58eadd2dfcd7b27;hb=4b33a4514f094dcf8ee8c7ad906a97a04112102f#l1140 As you can see we have an explicit check there for negative return values of snd_pcm_avail_update().
(In reply to comment #43) > Please, enable xrun debugging driver - see comment#16 - and look to 'dmesg' > output what goes wrong. I enabled debug for all cards, but i don't got much output. Only this in "/var/Log/messages": kernel: __ratelimit: 1 callbacks suppressed kernel: __ratelimit: 6 callbacks suppressed kernel: __ratelimit: 1 callbacks suppressed
I was told that snd_pcm_delay() overflowing with intel-hda is probably related to the issues in this report, so I'll add my details here. The initial report can be found at bug 497392. Currently testing on rawhide with kernel-2.6.29.3-154.fc11.x86_64 alsa-lib-1.0.20-1.fc11.x86_64 pulseaudio-0.9.15-11.fc11.x86_64 gnome-media-2.27.1-1.fc12.x86_64 http://www.declera.com/~yaneti/alsa/2.6.29.3-154.fc11.x86_64-alsa-info.txt related /var/log/messages http://www.declera.com/~yaneti/alsa/2.6.29.3-154.fc11.x86_64-gvc-pulse.log the whole kernel log , with enabled xrun debugging http://www.declera.com/~yaneti/alsa/2.6.29.3-154.fc11.x86_64-sound.log The result of this is not being able to use gnome-volume-control and pulseaudio dying in the process.
Could you try to add 'position_fix=1' as module option for the snd-hda-intel module?
kernel-2.6.29.4-75.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.4-75.fc10,hal-0.5.12-15.20081027git.fc10
For some (tried but failed to determine) reason I can no longer reproduce the snd_pcm_delay overflow and pusleaudio crashing when starting gnome-volume-control. Sorry for the noise, I'll keep you posted if it reappears.
(In reply to comment #48) > kernel-2.6.29.4-75.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an > update for Fedora 10. > http://admin.fedoraproject.org/updates/kernel-2.6.29.4-75.fc10,hal-0.5.12-15.20081027git.fc10 This fix it for me. :-) PA is now running fine. Thank you!
kernel-2.6.29.4-75.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-5527
*** Bug 504170 has been marked as a duplicate of this bug. ***
I am still having issues with snd-hda-intel and PulseAudio 0.9.15 on my new F11 install. The sound skips,stutters a lot and I get messages regarding ratelimit.c and "alsa-sink.c: Increasing wakeup watermark to xx ms" all the time when I am playing any sound .
kernel-2.6.29.5-84.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.5-84.fc10,hal-0.5.12-15.20081027git.fc10
kernel-2.6.29.5-84.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-6717
kernel-2.6.29.6-93.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.6-93.fc10,hal-0.5.12-15.20081027git.fc10
I started receiving these messages on F11, IBM Thinkpad T60p Jul 10 23:41:01 localhost pulseaudio[4241]: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Jul 10 23:41:01 localhost pulseaudio[4241]: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. Jul 10 23:41:01 localhost pulseaudio[4241]: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Jul 10 23:45:04 localhost pulseaudio[4241]: alsa-source.c: ALSA woke us up to read new data from the device, but there was actually nothing to read! Jul 10 23:45:04 localhost pulseaudio[4241]: alsa-source.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. Jul 10 23:45:04 localhost pulseaudio[4241]: alsa-source.c: We were woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Not sure how much this is related to the original problem. kernel-2.6.29.5-191.fc11.i586 alsa-lib-1.0.20-1.fc11.i586 pulseaudio-0.9.15-14.fc11.i586
kernel-2.6.29.6-93.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7573
(In reply to comment #22) > Anyone who has experienced the snd_pcm_avail() overflow (and associated > PulseAudio crashes) on intel-hda sound hardware, please update your kernel: > F11: kernel-2.6.29.1-70.fc11 or newer Are these of concern for this bug?: Jul 24 13:30:00 aughra pulseaudio[2292]: alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 3497584 bytes (19827 ms). Jul 24 13:30:05 aughra pulseaudio[2292]: alsa-util.c: snd_pcm_delay() returned a value that is exceptionally large: -2774376 bytes (-15727 ms). kernel: 2.6.29.6-213.fc11.i586 (current updates level) This is on a: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
Got the same problem with kernel 2.6.29.6-213.fc11.i586 on F11: E: alsa-util.c: snd_pcm_avail() ha restituito un valore molto grande: 4294964916 byte (24347873 ms). The message is written in italian, but is the same as "snd_pcm_avail() returned a value that is exceptionally large". Then pulseaudio kills itself because it uses too much cpu. The strange thing is that I get this problem only when using the (damned) Adobe flash player plugin. Sound card: 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
I see Lennart has expanded the scope of bug 501769 to include snd_pcm_avail() now - should this one be DUP'ed against it?
kernel-2.6.29.6-97.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.6-97.fc10
kernel-2.6.29.6-97.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8697
kernel-2.6.29.6-99.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.6-99.fc10
kernel-2.6.29.6-99.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8870
I'm seeing this bug on 2.6.30.5-43.fc11.x86_64. http://www.alsa-project.org/db/?f=df0b5f5d97231820057a93a2065e5803ffe92023
I'm not sure if I'm reporting in the right place, but I got a fresh install of F11, which is up-to-date, the sound glitches hard each time something starts playing. Linux 2.6.30.5-43.fc11.x86_64
Same here with fully updated FC11: (http://www.alsa-project.org/db/?f=1808e0a262b2677dc9bc414892663773e65416c1) [root@macbookpro ~]# grep -i alsa /var/log/{messages,dmesg} /var/log/messages:Oct 28 21:59:58 macbookpro kernel: ALSA sound/pci/hda/hda_intel.c:1102: Too big adjustment 32 ... /var/log/messages:Oct 28 22:00:04 macbookpro kernel: ALSA sound/pci/hda/hda_intel.c:636: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x006f000a /var/log/messages:Oct 28 22:03:35 macbookpro pulseaudio[2131]: alsa-source.c: Increasing minimal latency to 1.00 ms ... /var/log/messages:Oct 28 22:26:05 macbookpro pulseaudio[2131]: alsa-source.c: Increasing minimal latency to 1.00 ms /var/log/dmesg:ALSA sound/pci/hda/hda_codec.c:3797: autoconfig: line_outs=3 (0x1a/0x18/0x17/0x0/0x0) /var/log/dmesg:ALSA sound/pci/hda/hda_codec.c:3801: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) /var/log/dmesg:ALSA sound/pci/hda/hda_codec.c:3805: hp_outs=1 (0x14/0x0/0x0/0x0/0x0) /var/log/dmesg:ALSA sound/pci/hda/hda_codec.c:3806: mono: mono_out=0x0 /var/log/dmesg:ALSA sound/pci/hda/hda_codec.c:3809: dig-out=0x1e/0x0 /var/log/dmesg:ALSA sound/pci/hda/hda_codec.c:3817: inputs: mic=0x19, fmic=0x0, line=0x15, fline=0x0, cd=0x0, aux=0x0 /var/log/dmesg:ALSA sound/pci/hda/hda_codec.c:3819: dig-in=0x1f [root@macbookpro ~]# uname -a Linux macbookpro.excel.local 2.6.30.9-90.fc11.x86_64 #1 SMP Sat Oct 17 11:25:35 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [root@macbookpro ~]# lspci | grep Audio 00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1) [root@macbookpro ~]# rpm -qa | grep pulseaudio pulseaudio-0.9.15-17.fc11.x86_64 pulseaudio-libs-glib2-0.9.15-17.fc11.x86_64 pulseaudio-libs-0.9.15-17.fc11.x86_64 alsa-plugins-pulseaudio-1.0.21-2.fc11.x86_64 pulseaudio-utils-0.9.15-17.fc11.x86_64 xine-lib-pulseaudio-1.1.16.3-2.fc11.x86_64 pulseaudio-module-x11-0.9.15-17.fc11.x86_64 pulseaudio-module-bluetooth-0.9.15-17.fc11.x86_64 pulseaudio-module-gconf-0.9.15-17.fc11.x86_64
Created attachment 366500 [details] pulseaudio -vvv while executing aplay /usr/share/sounds/k3b_success1.wav # pulseaudio -vvv while executing # aplay /usr/share/sounds/k3b_success1.wav
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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
This can be updated to 11 per comments.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.