Bug 453908

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!