Description of problem: pulseaudio-0.9.10-1.fc9.x86_64 works fine. If I upgrade to a more recent pulseaudio (current rawhide is 0.9.11-0.6.git20080626), I see error messages of the form: pcm_pulse.c:274: pulse_write: Assertion `pcm->last_size >= (size * pcm->frame_size)' failed. coming out of /usr/lib64/alsa-lib/libasound_module_pcm_pulse.so It appears plugins-pulseaudio hasn't been upgraded since March 16 - does it need a rebuild against the 0.9.11 pulseaudio libraries? Version-Release number of selected component (if applicable): alsa-plugins-pulseaudio-1.0.16-4.fc9.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Could you please try to rebuild the following src.rpm, as I don't currently have access to a 64 bit system: ftp://ftp.zouric.com/public/alsa-plugins/alsa-plugins-1.0.17-0.1.rc2.fc9.src.rpm and let me know if this package fixes your problem.
Nope - obviously there's something subtle going on - I rebuilt alsa-plugins 1.0.17 from that src.rpm against the 0.9.11 version of pulseaudio-libs-devel, and the result still throws the assert. I'm looking at pcm_pulse.c:update_ptr(), and I think I know what the problem might be - pulse_write calls update_ptr, which sets last_size to whatever pa_stream_writeable_size() returns. We then check that there's enough space for 'size' frames of audio. In other words, if we ever try to write out a sample that's bigger than the immediately available buffer, we immediately blow chunks, instead of looping and writing the *available* amount out, and then trying again. Apparently, pulse 0.9.11 has different timing constraints, so where 0.9.10 was able to clear the buffers out on an almost guaranteed basis so we never overran, we now com into pulse_write() while the buffer is still partly full, we run out of space, and we die. This failure probably was *possible* under 0.9.10, just a lot harder to hit. Notice that pulse_read() has a 'while (remain_size > 0)' loop instead of an assert - I wonder if pulse_write should be doing something similar.
Reassigning to pulseaudio maintainer which happens to be upstream as well. This might be related to the pulseaudi glitch-free branch: http://0pointer.de/blog/projects/pulse-glitch-free.html
*** Bug 456624 has been marked as a duplicate of this bug. ***
*** Bug 452400 has been marked as a duplicate of this bug. ***
I'm seeing this too, Lennert let me know if there is anything I can do te help fix this, any patches I can test, things you want me to try etc. I can reproduce this on rawhide (including with the 0.9.11 final release which just hit rawhide) with pretty much any audio using application. To those in the CC, if you are also seeing this, do you happen to have an nvidia chipset ? For example on my x86_64 system lspci says: 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio I'm asking this because I've been looking at other bug reports and this might be related to having an nvidia chipset.
Additional note SDL applications, which still use esd by default due to SDL_AUDIODRIVER=esd in the environment, and other esd uses, such as the gnome system sounds are very quiet and sometimes (usually on close) tend to hang.
One last maybe important hint, when I start pulseaudio from a terminal I get: W: pcm_hw.c: SNDRV_PCM_IOCTL_DRAIN failed And each time I start an audio using app this message gets repeated a couple of times.
(In reply to comment #6) > To those in the CC, if you are also seeing this, do you happen to have an nvidia > chipset ? Nope, no NVidia chipset here, only a NVidia graphics card: $ lspci 00:00.0 Host bridge: Intel Corporation 82845 845 [Brookdale] Chipset Host Bridge (rev 11) 00:01.0 PCI bridge: Intel Corporation 82845 845 [Brookdale] Chipset AGP Bridge (rev 11) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7800 GS] (rev a2) 02:03.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 02) 02:03.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02) 02:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:05.0 Mass storage controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02) 02:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:09.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.40GHz stepping : 4 cpu MHz : 2429.920 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm up pebs bts bogomips : 4859.84 clflush size : 64 power management: I received the original assertion failure (pcm_pulse.c:274: pulse_write: Assertion `pcm->last_size >= (size * pcm->frame_size)' failed.) when starting gnome-terminal, 'su -' to root and launch k3b (which triggers the startup of artsd). The reason why I started k3b as root is because of some permission problem on my rawhide box I was too lazy too investigate/fix.
Not an NVidia audio chipset here either: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) The actual codec: % grep Codec /proc/asound/card0/codec#0 Codec: SigmaTel STAC9200 (although I'm quite convinced the problem is at a higher level - looking at the code indicates we're getting borked up before we ever get anywhere near the actual audio hardware - see the analysis in comment #2)
Created attachment 313132 [details] Hack out an assert that causes issues. This is total brute-force-and-ignorance. The assert trips unexpectedly, lose the assert. I have *not* investigated what Bad Things might happen if it keeps going, but the resulting library seems to Work For Me.
Well, fsck it - pulseaudio 0.9.11 came out, and then libcanberra started requiring 0.9.11, with the end result that I could either fix this bug, or deal wtih the fact that everybody and their pet llama is linked against libcanberra (as I found out when even frikking "ssh-askpass" started crashing). Since I couldn't figure out what the problematic assert was doing, or why, I did the attached brute-force-and-ignorance patch. Tom Duff's First Law of Systems Programming: "Never test for an error condition you don't know how to handle anyhow". So I just #if 0'ed the one assert, and the result *seems* to work just fine, including known cases that tripped the assert.
With the latest xine updates this is still broken... Firefox crashes every time on flash with audio
This is fixed in alsa-plugins 1.0.18rc which Jaroslav promised to upload soon (and before the freeze). This bug may be closed then.
1.0.18 rc3 is in rawhide
(In reply to comment #15) > 1.0.18 rc3 is in rawhide And I can confirm it actually fixes this issue! Great job guys!