GNOME Bugzilla – Bug 586034
Ekiga does not work with PulseAudio on Fedora11
Last modified: 2013-03-16 11:47:51 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 200@hd-telefonie.avm.de 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: https://bugzilla.redhat.com/show_bug.cgi?id=489724 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.
Your description seems to mention a bug about pulseaudio, not about Ekiga. <mezcalero> is right. Not anybody can code in C++.
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."
I cannot help, except: - there has recently been a fix for audio http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=rev&revision=23185, maybe it fixes your issue - there is a pulse ptlib audio plugin, but in trunk/master only, see http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/ptlib/trunk/plugins/
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.
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.
That sounds just like my gstreamer code... which would fix everything at once : pulse, jack, alsa, mosx, etc
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.
Hi, 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 http://www.pulseaudio.org/wiki/WritingModules * 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" http://www.pulseaudio.org/wiki/DeveloperDocumentation "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)." http://www.pulseaudio.org/wiki/Modules#RTPSDPSAPTransport "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. ../.. PA_PROP_MEDIA_ROLE 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);" http://www.pulseaudio.org/wiki/ApplicationProperties Best regards, Yannick
I actually think this bug report should be moved to pulseaudio "Pulseaudio does not work with Ekiga on Fedora 11".
(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. http://0pointer.de/blog/projects/skype.html
That just means Skype has a native pulseaudio plugin. That does not mean PulseAudio is permitted to break all native ALSA applications.
Well, let's wait the release of the unstable release (which has a pulse plugin) and improve that plugin...
It seems it works well now, see https://bugzilla.redhat.com/show_bug.cgi?id=489724#c25 I would be tempted to close this bug as well...
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: https://bugs.launchpad.net/pulseaudio/+bug/382234 Best regards, Yannick
(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: > https://bugs.launchpad.net/pulseaudio/+bug/382234 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.
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).
Please try on latest Fedora, which has 3.9.90, it should work, normally.
k. Let's assume this to be OBSOLETE by now.