Bug#539364: pulseaudio: alsa plugin eats all cpu with snd-hda-intel
Gonzalo Bermúdez
Version: 0.9.15-4.1
Severity: important
Applications that rely on ALSA and thus use the ALSA plugin for PulseAudio eat up 100% CPU time. Also, sound is choppy and stops working at some point i couldn't determine. Example of these apps are Ekiga, or packages that use sdl if libsdl-alsa is installed
However, native pulseaudio apps such as Rhythmbox or the same sdl apps with sdl-pulseaudio installed work perfectly.
I tried to obtain a console output for pulseaudio to attach here, but the file is huge and I didn't find anything I could identify as the source of the problem.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages pulseaudio depends on:
ii adduser 3.110 add and remove users and groups
ii consolekit 0.3.0-3 framework for defining and trackin
ii libasound2 1.0.20-3 shared library for ALSA applicatio
ii libasyncns0 0.3-1 Asyncronous name service query lib
ii libc6 2.9-23 GNU C Library: Shared libraries
ii libcap2 1:2.16-5 support for getting/setting POSIX.
ii libdbus-1-3 1.2.16-2 simple interprocess messaging syst
ii libflac8 1.2.1-1.2 Free Lossless Audio Codec - runtim
ii libgdbm3 1.8.3-6 GNU dbm database routines (runtime
ii libhal1 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share
ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library
ii libltdl7 2.2.6a-4 A system independent dlopen wrappe
ii libogg0 1.1.3-5 Ogg Bitstream Library
ii liboil0.3 0.3.16-1 Library of Optimized Inner Loops
ii libpolkit-db 0.9-4 library for accessing PolicyKit vi
ii libpolkit2 0.9-4 library for accessing PolicyKit
ii libpulse0 0.9.15-4.1 PulseAudio client libraries
ii libsamplerat 0.1.7-2 audio rate conversion library
ii libsm6 2:1.1.0-2 X11 Session Management library
ii libsndfile1 1.0.20-1 Library for reading/writing audio
ii libspeexdsp1 1.2~rc1-1 The Speex extended runtime library
ii libvorbis0a 1.2.0.dfsg-5 The Vorbis General Audio Compressi
ii libvorbisenc 1.2.0.dfsg-5 The Vorbis General Audio Compressi
ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra
ii libx11-6 2:1.2.2-1 X11 client-side library
ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension
ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip
Versions of packages pulseaudio recommends:
ii gstreamer0.10-pulseaudio 0.10.15-2 GStreamer plugin for PulseAudio
ii libasound2-plugins 1.0.20-1 ALSA library additional plugins
ii pulseaudio-esound-compat 0.9.15-4.1 PulseAudio ESD compatibility layer
ii pulseaudio-module-hal 0.9.15-4.1 HAL device detection module for Pu
ii pulseaudio-module-x11 0.9.15-4.1 X11 module for PulseAudio sound se
Versions of packages pulseaudio suggests:
pn paman <none> (no description available)
pn paprefs <none> (no description available)
pn pavucontrol <none> (no description available)
pn pavumeter <none> (no description available)
ii pulseaudio-utils 0.9.15-4.1 Command line tools for the PulseAu
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sjoerd Simons
> Package: pulseaudio
> Version: 0.9.15-4.1
> Severity: important
>
> Applications that rely on ALSA and thus use the ALSA plugin for PulseAudio
> eat up 100% CPU time. Also, sound is choppy and stops working at some point i
> couldn't determine. Example of these apps are Ekiga, or packages that use sdl
> if libsdl-alsa is installed However, native pulseaudio apps such as Rhythmbox
> or the same sdl apps with sdl-pulseaudio installed work perfectly.
>
> I tried to obtain a console output for pulseaudio to attach here, but the
> file is huge and I didn't find anything I could identify as the source of the
> problem.
Does this happen with all alsa applications ? It's important to note that alsa
plugins (like the pulseaudio one), do not always react as some alsa programs
assume even though they are a valid implementation of the alsa interface.
Most of thse support pulseaudio natively these days, such as SDL. I'm not sure
what the current situation with ekiga is, is it still broken when used with
pulse?
Sjoerd
--
It seems that more and more mathematicians are using a new, high level
language named "research student".
Gonzalo Bermúdez
> Does this happen with all alsa applications ? It's important to note that alsa
> plugins (like the pulseaudio one), do not always react as some alsa programs
> assume even though they are a valid implementation of the alsa interface.
It does happen with every ALSA applications I use. I've created
~/.asoundrc as instructed @ http://pulseaudio.org/wiki/PerfectSetup to
be sure everything goes through PulseAudio when ALSA audio is requested.
> Most of thse support pulseaudio natively these days, such as SDL. I'm not sure
> what the current situation with ekiga is, is it still broken when used with
> pulse?
What I did before submitting this bug report is:
- Follow the instructions at http://pulseaudio.org/wiki/PerfectSetup to
create ~/.asoundrc[1]
- Test Ekiga. Uses 100% CPU. Configured to use "Default (PTLIB/ALSA)"
device.
- With libsdl1.2-debian-alsa installed tested wesnoth for instance,
which relies on SDL, and found it was using 100% CPU.
- Replaced libsdl1.2-debian-alsa with libsdl1.2debian-pulseaudio. This
made wesnoth work seamlessly.
- Re-tested Ekiga. Still using 100% CPU.
I'm aware that SDL now natively supports pulse. I used it for testing
purposes only.
Is there anything else I can try? I've covered everything I can think
of, but am not afraid of further testing if needed.
[1]
gonzalob@gonzalo:~$ cat .asoundrc
# http://pulseaudio.org/wiki/PerfectSetup
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
--
Gonzalo Bermúdez | http://www.gonz0.com.ar/ | PGP 0xE2FC4825