On Sun, 2009-09-27 at 17:37 +0200, Sjoerd Simons wrote: > 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] gonza...@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
signature.asc
Description: This is a digitally signed message part