Ekiga hangs when using pulseaudio

Reported by tyler on 2007-05-06
94
This bug affects 18 people
Affects Status Importance Assigned to Milestone
ALSA Libraries
In Progress
Unknown
Ekiga
Invalid
Critical
PulseAudio
Fix Released
Unknown
alsa-plugins (Ubuntu)
Low
Unassigned
ekiga (Ubuntu)
Medium
Ubuntu Desktop Bugs
pulseaudio (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: ekiga

When using pulseaudio as soundserver, ekiga hangs when calling someone.

Steps to reproduce:

1) The audio wizard works with the pulseaudio settings (alsa emulation, default device)
2) Call someone
3) When the other side answeres the phone, ekiga hangs (does not respond any more)
4) Retry with normal alsa: everything works

Ari (a-r-i) wrote :

Someone can confirme that bug?

tyler, please try to run a backtrace (https://wiki.ubuntu.com/Backtrace) and attach the logfile.

Changed in ekiga:
status: New → Incomplete
tyler (durdon-tyler) wrote :

Here is a backtrace.

I used the audio test in the wizard to cause the hang.

but I didn't find any debugging packages to get better symbol output.

Will try to recompile with debugging enabled later.

tyler (durdon-tyler) wrote :

Ok, here is the right one, have overread the link to the debug symbols.

This backtrace has been produced by:

 - starting the program in the debugger
 - registering the sip account
 - calling an echo service
 - interrupting the unresponsive program
 - creating the backtrace

Changed in ekiga:
importance: Undecided → Medium
status: Incomplete → New

Thank you for your bug report. Do you still have this issue with an updated Ubuntu ? What version of Ekiga and Ubuntu are you running ?

Changed in ekiga:
assignee: nobody → desktop-bugs
status: New → Incomplete
tyler (durdon-tyler) wrote :

Hi!

I've tested this with feisty and the ekigra from the repository.

Now I'm testing on gutsy beta, and ekiga is still crashing.

Will Daniels (wdaniels) wrote :

I just discovered the same problem with latest gutsy - doesn't hang but crashes; output in terminal is...

ekiga: pcm_params.c:2351: sndrv_pcm_hw_params: Assertion `err >= 0' failed.
Aborted (core dumped)

Marking this as confirmed, I don't have time to forward this upstream now.

Changed in ekiga:
status: Incomplete → Confirmed
Martin-Éric Racine (q-funk) wrote :

I get the same problem as Will Daniels here. The content of my global /etc/asound.conf is:

pcm.pulse { type pulse }
ctl.pulse { type pulse }
pcm.!default { type pulse }
ctl.!default { type pulse }

Note that I get the same problem with both Ekiga (whatever is in Gutsy) and with Skype (1.4 and 2.0 beta).

Forwarded upstream.

Changed in ekiga:
status: Confirmed → Triaged

This is not an ekiga issue, it's either a pulseaudion one ( http://www.pulseaudio.org/ticket/23) or alsa one (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601) which are being worked upstream.

This is not an ekiga issue, it's either a pulseaudio one ( http://www.pulseaudio.org/ticket/23) or alsa one (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601) which are being worked upstream.

Changed in ekiga:
status: Triaged → Invalid
Changed in alsa-plugins:
importance: Undecided → Medium
status: New → Triaged
Changed in pulseaudio:
importance: Undecided → Medium
status: New → Triaged
Changed in pulseaudio:
status: Unknown → New
Changed in alsa-lib:
status: Unknown → In Progress
Changed in ekiga:
status: Unknown → Invalid
Ulrik Mikaelsson (rawler) wrote :

Could this be related to bug #175028?

Ulrik Mikaelsson (rawler) wrote :

Sorry, wrong bug. My bad, instead, isn't this related to bug #109439?

Carlos (dspcarlos) wrote :

Hi.

I got the same problem using mp4live (from Mpeg4ip project), but using the file plugin.
I can successful use the file plugin using arecord, but mp4live dosent work, and say this:

mp4live: pcm_params.c:2351: sndrv_pcm_hw_params: Assertion `err >= 0' failed.

Jonathan Rogers (jonner) wrote :

I get the same error with the speaker-test program from alsa-utils:

speaker-test: pcm_params.c:2351: sndrv_pcm_hw_params: Assertion `err >= 0' failed.

However, some ALSA apps, such as aplay, alsa-mixer, mplayer with "-ao alsa", and exaile work just fine with the "pulse" pcm and control plugins. OTOH, several SDL apps skip and even crash the PulseAudio server when using the alsa pulse plugin. The same SDL apps work much better when using the SDL esd or pulse plugins to connect to the same server.

So, I suspect the bug lies in the PulseAudio server and/or the pulse alsa plugin. It seems the server must be at least partly to blame, since some client connections (mostly from the alsa plugin) crash it.

Jonathan Rogers (jonner) wrote :

I'm no longer so certain there's a bug in the PulseAudio server. Some ALSA clients (such as SDL) cause pulseaudio to use all available CPU time until it writes "Soft CPU time limit exhausted, terminating." to its stdout and exits. I'm not sure exactly where that message comes from or what causes pulseaudio to exit. It may be the kernel forcibly killing the process, so this may be more a configuration issue than a bug in pulseaudio.

Chow Loong Jin (hyperair) wrote :

This also happens in Hardy, fully updated.

Daniel T Chen (crimsun) wrote :

(Lowering importance because there is a viable workaround.) Please use "pasuspender -- ekiga" in the meantime.

Changed in pulseaudio:
importance: Medium → Low
Changed in alsa-plugins:
importance: Medium → Low

The IRC channel for #pulseaudio mentioned a recent fix in libasound2-plugins which might be the fix we need so Ekiga can work this way.

Also I don't know what package contains this "pasuspender" command. Please push for an upgrade of libasound2-plugins within gutsy.

Quote:
=====
(09:35:52 AM) sjoerd: joebaker: if their intended 8.04 has alsa-plugins >= 1.0.16-1 as seen in debian, it should just work with ekiga
=====

Thanks!
-Joe Baker

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package alsa-plugins - 1.0.15-1ubuntu3

---------------
alsa-plugins (1.0.15-1ubuntu3) hardy; urgency=low

  * Backport remaining pcm_pulse.c patches from hg tip (LP: #112948)
    that allow Ekiga to work again with PulseAudio
    - debian/patches/pulse-{minmax,assert}.diff

 -- Daniel T Chen <email address hidden> Fri, 29 Feb 2008 12:28:40 -0500

Changed in alsa-plugins:
status: Triaged → Fix Released
Luke Yelavich (themuso) wrote :

Marking the pulseaudio task as fix released as the plugin has been fixed. Please re-open if there are any more issues.

Changed in pulseaudio:
status: Triaged → Fix Released

I have the latest hardy with libasound2-plugins Version: 1.0.15-1ubuntu3

my .asoundrc look like this

pcm.pulse {
    type pulse
}
ctl.pulse {
    type pulse
}
pcm.!default {
    type pulse
}
ctl.!default {
    type pulse
}

My Ekiga uses the default devices for audio input output (Device default)
under Multimedia Setup the ouput is set to automatic and the input to PulseAudio-Soundsever.

My Ekiga keeps crashing when I try to call somebody.

@daniel The "pasuspender -- ekiga" workaround does not work for me. I get this message:

  WARNING: Sound server is not local, not suspending.

I'm with Intrepid Ibex with latest updates.

Changed in pulseaudio:
status: New → Fix Released
Martin-Éric Racine (q-funk) wrote :

Is this still an issue in Jaunty or Karmic?

C Anthony Risinger (extofme) wrote :

im running karmic all updates as of ten minutes ago...

the only way i have been able to get ekiga to work (echo test) is to kill pulseaudio before starting it. "pasuspender -- ekiga" doesnt do the trick. other gnome apps work fine like sound-recorder/banshee/flash/etc.

additionally, i receive these symptoms:
http://osdir.com/ml/debian-bugs-dist/2009-09/msg09233.html

when pulseaudio is running, many operations within ekiga after connecting to a call result in the program hanging and consuming 100% CPU.... even just trying to open the preferences.

Yannick Defais (sevmek) wrote :

Hi,

Using Jaunty I have huge delay rending Ekiga barely usable (5 seconds delay). Tested on 2 really different machines. Removing Pulse Audio fix the issue for me as well.

Upstream planned to add a Pulse Audio plugin as default configuration for Ekiga 3.4.

In the meantime, I've no clue how to fix this issue without breaking Ubuntu default audio setup.

Best regards,
Yannick

Yannick Defais (sevmek) wrote :

Please attach this upstream bug:
https://bugzilla.gnome.org/show_bug.cgi?id=586034

Changed in ekiga (Ubuntu):
status: Invalid → Confirmed

Same bug in Ubuntu 9.10 (Karmic).
Ekiga works until someone call me; answering to a call make Ekiga usgin 100% CPU and give no answer.
Ciao

Martin Capitanio (capnm) wrote :

I can confirm similar problems. After upgrading to 9.10 ekiga-sound stopped working on all our (8) computers. 100% CPU last. Video is working. You can hear about 1 second distorted sound, then no sound at all.

Martin Capitanio (capnm) wrote :

Additional - ekiga freezes by trying to cancel the call or opening the configuration-menu during the connection

Can confirm this bug on three different boxes. Ekiga doesn't work on Karmic using pulse. This essentially leaves Ubuntu without a SIP-capable phone application. Empathy doesn't count as it's SIP support is close to non-existent (can't connect to sipgate for example, fails to place calls repeatedly). I think this situation needs a fix asap.

dimafogo (dimafogo) wrote :

I've expirienced the same problem today on my laptop (Ubuntu 9.10 + ekiga 3.2.5 + pulseaudio 0.9.19ubuntu4.1) with the same symptoms as in captn's post above.

Manolinux (mu) wrote :

I asked my brother to test this bug in his Debian Sid, and the hang didn't happen. It seems that it is an Ubuntu-only bug.

somejan (somejan) wrote :

I'm also having this problem. I can't call anyone due to bug #332543, but I get the same problem when I try to test the sound events in the sound events preferences: ekiga uses 100% cpu. The UI is still responsive, but when I try to quit ekiga that doesn't work until I kill it manually.
Same problem when run under pasuspender.
If I kill pulseaudio first, playing the test sounds works more or less, though there is still sometimes crackling while playing a test sound.
Skype and other audio work fine.

Ubuntu 9.10, Ekiga 3.2.5, snd_hda_intel driver
soundcard (according to lspci): Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)

somejan (somejan) wrote :

I installed a patched 3.2.6 version from https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/332543/comments/20 , which fixes me not being able to call.

When I call the echo test, I get video but no audio at all. The volume change icon below the video stays greyed out.

When I try to play a test sound (in the sound events preferences section) through the default device with pulseaudio enabled, that works fine the first time. When I repeatedly play a sound, it works fine for the first 10 seconds or so, after that it starts crackling. If I continue playing the test sound, the crackling stays for another 2 to 20 seconds, and then sound stops and ekiga hangs at 100% cpu. The UI also becomes unresponsive and I have to kill it. Banshee is having no trouble playing music at the same time, so PulseAudio is not having any problems.

When I try to play a test sound through the "HDA Intel (PTLIB/ALSA)" device with pulseaudio suspended or pulseaudio enabled but not actually playing anything at that moment, I get sound but it is as if every 50 ms sample gets repeated for 5 seconds before ekiga decides to play the next 50 ms part. Ekiga still advances through the sound file, but veeeeerrrrryyyy slowly and stuttery.
This behaviour is the same I had with PulseAudio under Jaunty when I tried to play any kind of sound after my laptop resumed from a suspend. Killing PA every time I resumed was a workaround there. In Karmic this PA problem was fixed.

Changed in ekiga:
importance: Unknown → Critical
status: Invalid → Unknown
Changed in ekiga:
status: Unknown → Invalid
Eugen Dedu (eugen-dedu) wrote :

Please use ekiga 4.0.0, it fixes such issues. By the way, there is now a pulse audio plugin.

Changed in ekiga (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.