Bug 453908 - alsa-plugins-pulseaudio doesn't play nice with rawhide pulseaudio
alsa-plugins-pulseaudio doesn't play nice with rawhide pulseaudio
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: alsa-plugins (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Eric Moret
Fedora Extras Quality Assurance
:
: 452400 456624 (view as bug list)
Depends On:
Blocks: F10DesktopBlocker
  Show dependency treegraph
 
Reported: 2008-07-03 02:18 EDT by Valdis Kletnieks
Modified: 2008-09-14 10:18 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-13 20:59:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Hack out an assert that causes issues. (410 bytes, patch)
2008-07-31 17:05 EDT, Valdis Kletnieks
no flags Details | Diff

  None (edit)
Description Valdis Kletnieks 2008-07-03 02:18:08 EDT
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:
Comment 1 Eric Moret 2008-07-03 04:19:14 EDT
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.
Comment 2 Valdis Kletnieks 2008-07-03 07:04:51 EDT
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.
Comment 3 Eric Moret 2008-07-03 11:13:50 EDT
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
Comment 4 Hans de Goede 2008-07-25 06:29:29 EDT
*** Bug 456624 has been marked as a duplicate of this bug. ***
Comment 5 Hans de Goede 2008-07-25 06:30:16 EDT
*** Bug 452400 has been marked as a duplicate of this bug. ***
Comment 6 Hans de Goede 2008-07-25 06:42:47 EDT
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.
Comment 7 Hans de Goede 2008-07-25 06:54:46 EDT
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.
Comment 8 Hans de Goede 2008-07-25 07:18:51 EDT
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.
Comment 9 Erik van Pienbroek 2008-07-25 08:19:20 EDT
(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.
Comment 10 Valdis Kletnieks 2008-07-25 14:49:31 EDT
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)
Comment 11 Valdis Kletnieks 2008-07-31 17:05:26 EDT
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.
Comment 12 Valdis Kletnieks 2008-07-31 17:07:31 EDT
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.
Comment 13 Ilya Eremin 2008-08-31 10:19:29 EDT
With the latest xine updates this is still broken... Firefox crashes every time on flash with audio
Comment 14 Lennart Poettering 2008-09-09 15:59:19 EDT
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.
Comment 15 Matthias Clasen 2008-09-13 20:59:00 EDT
1.0.18 rc3 is in rawhide
Comment 16 Hans de Goede 2008-09-14 10:18:39 EDT
(In reply to comment #15)
> 1.0.18 rc3 is in rawhide

And I can confirm it actually fixes this issue! Great job guys!

Note You need to log in before you can comment on or make changes to this bug.