After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 586034 - Ekiga does not work with PulseAudio on Fedora11
Ekiga does not work with PulseAudio on Fedora11
Product: ekiga
Classification: Applications
Component: general
Other All
: Normal major
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Reported: 2009-06-16 19:31 UTC by Martin Jürgens
Modified: 2013-03-16 11:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26

Description Martin Jürgens 2009-06-16 19:31:58 UTC
Please describe the problem:
I am trying to use Ekiga on Fedora 11 with PulseAudio.

Sadly the whole thing does not work and audio is just stuttering. Also, high cpu usage appears.

I only run into this if I have another sound application playing sound.

Steps to reproduce:
On Fedora 11:

1. Open Totem and play music
2. Open Ekiga 
3. Call

Actual results:
You hear stuttering and crackling sound. The PulseAudio list of applications playing sound just display garbage.

Expected results:
Should work flawlessly.

Does this happen every time?
Yes, if you are listening to music before staring Ekiga

Other information:
The original bug report is here: but the assignee can not reproduce it and:

<mezcalero> pirast: i spent some time on it a while ago just to find out that nothing was wrong, but i had to to read that mess C++ code of ekiga
<mezcalero> pirast: which makes me a little less than enthusiastic about looking into it again...

so maybe you have an idea about what might be wrong. In the rhbz entry, there may be also find more information.
Comment 1 Damien Sandras 2009-06-17 07:28:21 UTC
Your description seems to mention a bug about pulseaudio, not about Ekiga.

<mezcalero> is right. Not anybody can code in C++.
Comment 2 Richard Schwarting 2009-08-04 06:39:29 UTC
Is this hot potato? 

His description mentions a bug that gets assigned to pulseaudio and Lennart, but which includes conclusions such as:

"Hmm, it seems as if Ekiga misbheaves and underruns all the time and even
reconnects. No clue. If I'd knew how to reproduce this I'd have a closer look."

So, if you had any idea what role Ekiga might play (since other applications seem to use PulseAudio more or less fine), your valuable input would be appreciated.  All we users know is that "I tried to use Ekiga, it didn't work.  I tried to use Skype, it did work."
Comment 3 Eugen Dedu 2009-08-04 13:09:55 UTC
I cannot help, except:
- there has recently been a fix for audio, maybe it fixes your issue
- there is a pulse ptlib audio plugin, but in trunk/master only, see
Comment 4 Snark 2009-08-30 07:44:18 UTC
When will that pulse audio plugin be release as stable? Pulseaudio is finding its way in more and more user's box, so that is getting annoying.
Comment 5 Damien Sandras 2009-08-30 07:51:29 UTC
Julien, Derek has done a prerelease, but is not working anymore on it (I think).

If you have some spare time, it could be a nice task for you. (testing, debugging, fixing). There is already a good basis to work on. Actually, it might even be ready.
Comment 6 Snark 2009-08-30 09:26:16 UTC
That sounds just like my gstreamer code... which would fix everything at once : pulse, jack, alsa, mosx, etc
Comment 7 Eugen Dedu 2009-08-30 18:43:28 UTC
The plugin is in the trunk.  Fedora guys told me that the plugin does not work on stable branch.

This plugin will be released/usable when we release the trunk.  I would say that in one month, once the stable branch is released, we can allocate a few days to stabilise the trunk/master.
Comment 8 Yannick 2009-09-06 07:21:29 UTC

Some documentation about pulse audio:

Developing Modules

"There are several reasons for writing loadable modules for PulseAudio:

    * For low latency applications such as VOIP: load the VOIP core directly into PulseAudio and have a slim GUI frontend to control it.

There is currently a little bit of documentation available how to write loadable modules for PulseAudio. Beyond this, read the source, Luke! If you are interested in writing new modules feel free to contact the authors in case you have any questions. 

    * Writing Modules
    * Core API
    * Module API
    * Module Arguments API
    * Threading Model
    * A discussion about writing a sink
    * Coding Style 

Some things that might be relevant for people hacking on some of the modules:

    * BlueZ issues/limitations list
    * ALSA issues/limitations list
    * Building the sources on Mac OS X"

"RTP/SDP/SAP Transport

PulseAudio can stream audio data to an IP multicast group via the standard protocols RTP, SAP and SDP (RFC3550, RFC3551, RFC2327, RFC2327). This can be used for multiple different purposes: for sharing a single microphone on multiple computers on the local LAN, for streaming music from a single controlling PC to multiple PCs with speakers or to implement a simple "always-on" teleconferencing solution.

The current implementation is designed to be used exclusively in local area networks, though Internet multicasting is theoretically supported. Only uncompressed audio is supported, hence you won't be able to multicast more than a few streams at the same time over a standard LAN.

PulseAudio implements both a sender and a receiver for RTP traffic. The sender announces itself via SAP/SDP on the same multicast group as it sends the RTP data to. The receiver picks up the SAP/SDP announcements and creates a playback stream for each session. Alternatively you can use any RTP capable client to receive and play back the RTP data (such as mplayer, see HowToListenToTheRtpStream)."

"Setting Application Properties

PulseAudio allows setting of all kinds of properties for clients and streams. They are roughly modelled after X11 window properties, however typeless: usually formatted UTF-8 strings and sometimes binary. These properties can be used for a variety of purposes: for enhancing volume control UIs by showing icons/application names for clients/streams, for doing policy decisions (i.e. route 'phone' streams to a different device than 'music' streams) as well as effects (i.e. if we know which X11 window a stream belongs to we can implement 'volume-follows-focus').

The complete list of currently known client/stream properties is defined in proplist.h. The list will be extended in the future. Some of these properties can be and are deduced automatically from the process environment, however others cannot and aren't.

Only applications that directly call into the PA API or the libcanberra API may set those properties directly (for now at least). However, only the minority of code interfaces directly with those APIs. To allow setting the properties for other applications as well here are a few hints. For now this only describes how to set PA_PROP_APPLICATION_NAME, PA_PROP_APPLICATION_ICON_NAME, and PA_PROP_MEDIA_ROLE which are the most important ones and which are currently already being used in PulseAudio.

Please note that none of the hints listed here requires you to add an explicit dependency on PA to your application in any way! Adding these lines will not influence the portability to other sound systems. In fact at least the Gtk+ related functionality listed here is something everyone should probably do, not just the folks doing audio/media programming. 


This property should contain a short string that describes the role of a media stream, where role is one of:

   5. "phone": for phone data (i.e. voip speech audio)

This is a property of the actual streamed data, not so much the application. However usually it is still safe to simply set a process-global environment variable.

For Glib applications:

g_setenv("PULSE_PROP_media.role", "video", TRUE);"

Best regards,
Comment 9 Damien Sandras 2009-09-19 08:33:04 UTC
I actually think this bug report should be moved to pulseaudio "Pulseaudio does not work with Ekiga on Fedora 11".
Comment 10 Peter Robinson 2009-09-23 08:54:15 UTC
(In reply to comment #9)
> I actually think this bug report should be moved to pulseaudio "Pulseaudio does
> not work with Ekiga on Fedora 11".

It seems that skype now works with PulseAudio so I'm not sure that the PA team would accept it.
Comment 11 Damien Sandras 2009-09-23 09:03:43 UTC
That just means Skype has a native pulseaudio plugin.
That does not mean PulseAudio is permitted to break all native ALSA applications.
Comment 12 Eugen Dedu 2009-09-23 09:12:24 UTC
Well, let's wait the release of the unstable release (which has a pulse plugin) and improve that plugin...
Comment 13 Eugen Dedu 2009-10-23 19:30:50 UTC
It seems it works well now, see  I would be tempted to close this bug as well...
Comment 14 Yannick 2009-11-08 12:09:05 UTC
As side note, in Ubuntu latest release (Karmic), Ekiga is severely broken for some users (at least): "no sound" (and probably high CPU usage too; I'm waiting confirmation on this...)


Best regards,
Comment 15 Peter Robinson 2009-11-09 08:17:25 UTC
(In reply to comment #14)
> As side note, in Ubuntu latest release (Karmic), Ekiga is severely broken for
> some users (at least): "no sound" (and probably high CPU usage too; I'm waiting
> confirmation on this...)
> Reference:

I've had similar reports of high CPU in ekiga since v3.0 in Fedora 10 and later although I've never been able to reproduce the issue. The no sound is a regular report. I'm hoping the later will go away with native PA support, former might be one for a separate bug. ekiga always features high up on a power top too.
Comment 16 idra 2009-12-05 19:43:33 UTC
FWIW I have problems in F12 too.
Often the call starts and goes on for a while then suddenly audio stops (but video keeps going) and I see 100% cpu usage until I kill ekiga (no way to close it as it stop responding).
Comment 17 Eugen Dedu 2012-10-17 19:37:44 UTC
Please try on latest Fedora, which has 3.9.90, it should work, normally.
Comment 18 Tobias Mueller 2013-03-16 11:47:51 UTC
k. Let's assume this to be OBSOLETE by now.