Red Hat Bugzilla – Bug 481722
Ekiga audio playback broken
Last modified: 2010-06-10 18:41:30 EDT
Description of problem:
When calling "Echo test", I see the picture captured from my webcam, but audio is silent. With older versions, a voice would introduce the echo test service, then play back video and audio captured by the local devices.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start ekiga
2. Call "Echo test" (sip:email@example.com)
Video is replayed correctly, audio is silent.
Voice explains service, then you hear your own voice or whatever noises are in your room with a slight delay.
Changes of audio devices wouldn't help.
With debugging enabled ("ekiga -d1"), I see these error(?) messages:
2009/01/27 12:19:27.742 0:08.229 Media Patch:0x214950 ALSA Could not write 0 2048 Success
2009/01/27 12:19:27.976 0:08.463 Media Patch:0x214950 ALSA Could not write 0 376 Success
2009/01/27 12:19:28.244 0:08.731 Media Patch:0x214950 ALSA Could not write 0 680 Success
What are the older versions? Have previous 3.x releases worked? Can you also check in the preferences that all the audio codecs are enabled?
I am having the same problem on my laptop
$ rpm -q ekiga
I cannot hear anything nor speak, and in my case the webcam also fails...
I have three popup when I try to call the Echo test:
"Error while accessing video device HP Webcam (PTLIB/V4L2)"
"Error while opening audio input device HDA Intel (PTLIB/ALSA)"
"Error while opening audio output device HDA Intel (PTLIB/ALSA)"
Switching in the preferences windows the Audio device to any of the possibilities given make disapearing the last 2 errors messages about audio (but not the one about the webcam) and I still have no sound.
I know that the previous version of Ekiga worked on my laptop.
My sound card is:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
FYI ekiga-3.0.2-1.fc10.i386 works on my desktop with a nVidia sound card:
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler (MCP) (rev a1)
Finally I could not paste any debug info since I fail to run "ekiga -d1", "ekiga -d" or "ekiga --debug" despite what the --help says.
Settings the audio device to
"Default (PTLIB/ALSA)" finally solved the problem for after restart of the program.
I also had to change the settings for the webcam to get it working.
So problem is solved for me :)
There's also an issue with sounds with kernel version 18.104.22.168-159.fc10 see bug https://bugzilla.redhat.com/show_bug.cgi?id=477954 for more details. Nils is this fixed for you as well?
(In reply to comment #4)
> There's also an issue with sounds with kernel version 22.214.171.124-159.fc10 see bug
> https://bugzilla.redhat.com/show_bug.cgi?id=477954 for more details. Nils is
> this fixed for you as well?
I'm CCed on that bug because I had sound problems on my laptop (which is working again, thanks for asking). I try to use ekiga and the webcam on my desktop machine which has a different sound chipset:
00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
I didn't know the exact old package versions I used, so I used the Fedora 10 Live CD and installed ekiga and sox in the GA versions on top of that (sox for checking out whether sound works correctly). In that constellation (everything on GA level, no updates) it worked for me. These are the packages I installed (ekiga + sox + deps):
sox-14.1.0-5.20081105cvs.fc10 Thu 29 Jan 2009 09:03:44 AM EST
libao-0.8.8-5.fc10 Thu 29 Jan 2009 09:03:43 AM EST
gsm-1.0.12-6.fc9 Thu 29 Jan 2009 09:03:43 AM EST
ekiga-3.0.1-4.fc10 Thu 29 Jan 2009 09:03:09 AM EST
opal-3.4.2-1.fc10 Thu 29 Jan 2009 09:03:07 AM EST
ptlib-2.4.2-1.fc10 Thu 29 Jan 2009 09:02:46 AM EST
Nils, is this still a problem?
Unfortunately yes, with these package versions:
Curiously, downgrading to the GA/live media versions above (as well as alsa* to 1.0.18-6.rc3.fc10) didn't help either, but I'm at a loss what could cause this then... Here's the error I get when running with "-d2":
2009/02/18 11:57:39.359 0:10.028 Media Patch:0xa85950 ALSA Could not write 0 448 Success
2009/02/18 11:57:39.411 0:10.080 GMVideoOut...r:0x1f2950 X11 XQueryShmExtension success
2009/02/18 11:57:39.417 0:10.086 GMVideoOut...r:0x1f2950 X11 Unknown X Event 19 received
2009/02/18 11:57:39.492 0:10.161 Media Patch:0xa85950 ALSA Could not write 0 448 Success
2009/02/18 11:57:39.643 0:10.312 Media Patch:0xa85950 ALSA Could not write 0 2048 Success
I've tried it with pulseaudio switched off as well to no avail, so that maybe would leave the kernel, but I don't have the time right now to switch to the GA one. I'll leave this as "NEEDINFO" (from me) until I could check whether that makes a difference...
I can confirm this, on a Fedora X86_64 with a ADI 1988B sound chip. I had a working 3.0.2 setup, which broke on an update performed last Thursday. Skype works OK, using the pulse device. Tried last kernel.org alsa drivers, same result.
Created attachment 332819 [details]
seems that Feb,17 is the bad day
In reply to #3, changing the sound device doesn't help for me. To get debug output from Ekiga use "ekiga -d 4", not "ekiga -d4".
I can also confirm this with 3.0.2 on Fedora 10 x86_64. I get no audio playback at all with Intel HDA on my laptop AND Sound Blaster Audigy 2 ZS on my desktop. All other capture/playback work for both machines, and ekiga was working fine in Fedora 9 with ekiga-2.
Also getting a weird error: sometimes when I call firstname.lastname@example.org, it crashes X, and I'm back at GDM login screen on my laptop.
I see the same problem with ekiga on Intel HDA on Fedora 11 Beta.
I got the same results when using the Ekiga account, same Alsa messages, but after trying a Gizmo5 account, echo testing worked flawlessly. This may be a service provider issue. I've been able to make outgoing calls without problem since.
Do you have an ekiga.net account that you can use to test with the echo service?
(In reply to comment #14)
> Do you have an ekiga.net account that you can use to test with the echo
Yes, I cannot make any calls with the Ekiga service (it sits in standby or there's no audio). If I switch accounts, it works fine. This applies to calling other SIP targets that are echo tests and to ekiga.net's echo test service.
For example, when logged into my ekiga.net account I cannot call:
sip:*email@example.com (Gizmo5 Echo Test)
sip:firstname.lastname@example.org (Ekiga.net Echo Test)
When logged into a third party (sipphone/gizmo) SIP service, I can call:
email@example.com (Skype Gateway) *WORKS*
*firstname.lastname@example.org (sipbroker test announcement) *WORKS*
Any POTS via a google voice account. Clear as day. *WORKS*
I *AM* having lots of random call failures which I can't figure out, but audio is working fine.
Mike, can you check all the audio codecs are enabled under preferences -> audio -> codecs. Something working with one provider would be either a codec issue (can't negotiate a compatible codec between the two end points) or possibly a network/firewall issue.
Those that are still having problems can you ensure you are using the "Default PTLIB/ALSA" sound device as opposed to the the specific HW sound device. It looks like pulse audio takes that and you need to use the default option which then uses pulseaudio. I'm hoping we'll have a proper PA plugin before too long.
Fedora 10 AND 11 problems.
I have the same problems with Ekiga and No audio playback, I upgraded to Fedora 11 in the hope it might be fixed, but no luck. Confirm that the receiver can hear my microphone, but no sound replayed through my speaker. All devices in Ekiga configured to Default PTLIB/ALSA.
In Gnome sound prefs -> [Applications] tab, can see two ALSA plugins for Ekiga while call is active. First plugin entry has volume slider at zero, 2nd plugin entry is slider @ 100%. In the GnomeSoundPrefs [Sound Effects] tab, clicking on the alert entries does produce sound. Also no other issues playing sound in other applications.
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
Subsystem: ASUSTeK Computer Inc. Device 82ea
Flags: bus master, fast devsel, latency 0, IRQ 22
Memory at f7ff8000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
$ modinfo snd-hda-intel
description: Intel HDA driver
vermagic: 126.96.36.199-167.fc11.x86_64 SMP mod_unload
You may wish to upgrade to Fedora 11 which has ekiga 3.2.5 which is much improved.
I experience the same effect in Fedora 11, that is, when Ekiga doesn't complain that it can't register me and then segfaults. (There might be something special about me, as I've never once in the past 6 years been able to complete a call to another user with Ekiga or its predecessor, regardless of computer or network configuration. :| I miss my echo.)
I am also facing this issue.
Sometime I start to hear the echo which suddenly stops. Sometime I just restart and it works again.
I also face the problem of ekiga not accepting me to register (so the other people don't see me online)
But in my case I did succeed several time to have talk with someone through ekiga :-)
There's a bug for ekiga audio with pulseaudio here. It should be fixed in ekiga 3.2.6 which is due shortly.
And the 2.6.30 kernel has a number of fixed for audio for those with intel HDA audio which has also caused some issues.
I have had the situation described in #18 on three machines, all running FC11 updated as of (more or less) today. I can connect to the echo server, but there is no sound whatsoever.
I have used Ekiga successfully on two of these machines, but it broke somewhere along the FC10 update path if my memory is correct.
But, today everything started to work on one machine after invoking pavucontrol (!).
Is this this, as of now, a question of setting the levels for the alsa device used by Ekiga, but otherwise effectively hidden below pulseaudio?
I got another machine up & running using alsamixer -c0.
I have a similar problems:
No sound on ekiga echo test service
Looks like the mic does work (input meter shows input)
Linux 188.8.131.52-64.fc11.i586 #1 SMP Fri Sep 25 04:30:19 EDT 2009 i686 i686 i386 GNU/Linux
Started ekiga with -d 4 option and will try to add the logfile.
I really hope this problem will be solved soon, ekiga looks like an ideal H323 client.
Created attachment 366257 [details]
logfile of ekiga -d 4
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
I am seeing exactly the same problem as described in the original bug report, both on Fedora 12, and now also with a fresh upgrade to Fedora 13 with packages current as of today.
Hardware: Intel 82801H (ICH8 Family) HD Audio Controller (on Dell XPS M1330)
Notes: 1. I am sometimes seeing "ALSA Could not write" messages in the ekiga -d 1 output as mentioned in the original bug report, but the attached ekiga -d 4 trace does not show them.
2. I tried with a new user account on F13 keeping all setting at their defaults. Same results as with my old configuration files present.
3. I definitely had output sound some time ago. There is an old known internal microphone problem on the XPS M1330 (input volume far too low to be usable), but output definitely worked (voice in ekiga echo test). I was trying to see if the microphone problem had been solved, but now even output does not work.
4. This problem seems to be persistent in Ubuntu as well, see
Created attachment 422472 [details]
Logfile from ekiga -d 4
This particular problem is resolved. It was due to my router blocking ports 1720 and 5060. (Strangely enough, after opening the ports, the echo test only started working half an hour and several tests later, while I could immediately call out through another provider.)
That leaves only two different bugs, the resolution of either one would make ekiga actually usable for me...
Also, ekiga does not actually make it very easy to debug these network problems, the box about network settings which pops up when starting ekiga does not make it clear that there is a real problem (as it seemed that the network was up all right). Someone not familiar with VoIP would not directly guess that there was a real router NAT problem, and there is no clear diagnostics available as far as I can tell. A clearer message would have save A LOT of time.
More wierdness: It is possible to break ekiga sound in ways unrelated to network port issues. I have not been able to reproduce this in a reliable way, but seems to be related to other applications accessing pulseaudio.
Then the following happens:
1. Start ekiga
2. Go to Preferences -> Sound Events -> Play
hear sound on incoming calls just fine
3. Close preferences
4. Click echo test, no sound audible
5. Repeat Step 2, now no sound here, either!
6. Connect Bluetooth headset, but leave audio settings on internal input/output
7. Now echo test works
8. Close ekiga
9. Open ekiga, repeat step 2, works
10. Repeat step 3 and 4, echo test still works
11. Repeat step 2 once more, sound does not work!
Something is seriously @#$%^& up...
(In reply to comment #32)
> More wierdness: It is possible to break ekiga sound in ways unrelated to
> network port issues. I have not been able to reproduce this in a reliable way,
> but seems to be related to other applications accessing pulseaudio.
> Then the following happens:
> 1. Start ekiga
> 2. Go to Preferences -> Sound Events -> Play
> hear sound on incoming calls just fine
> 3. Close preferences
> 4. Click echo test, no sound audible
> 5. Repeat Step 2, now no sound here, either!
> 6. Connect Bluetooth headset, but leave audio settings on internal input/output
> 7. Now echo test works
> 8. Close ekiga
> 9. Open ekiga, repeat step 2, works
> 10. Repeat step 3 and 4, echo test still works
> 11. Repeat step 2 once more, sound does not work!
> Something is seriously @#$%^& up...
Its not really necessary to use that sort of terms. The issue you have isn't related to this bug. It might be related to this bug 602175 else please open a new bug. Its likely your issue will be fixed when the new major version comes out that will support pulseaudio.
(In reply to comment #33)
> Its not really necessary to use that sort of terms.
Sorry, I didn't mean to be rude. I tried very hard to produce a meaningful bug report, but the behavior was very unreproducible, with lots of strange interactions with whatever else was going on.
> The issue you have isn't
> related to this bug. It might be related to this bug 602175 else please open a
> new bug. Its likely your issue will be fixed when the new major version comes
> out that will support pulseaudio.
So you are saying it's better to stay put rather than waste time on hunting this down? I'd like to provide more information if it helps because I feel it's coming close (after trying one Fedora version after the other) to actually being usable on my hardware...
> > The issue you have isn't
> > related to this bug. It might be related to this bug 602175 else please open a
> > new bug. Its likely your issue will be fixed when the new major version comes
> > out that will support pulseaudio.
> So you are saying it's better to stay put rather than waste time on hunting
> this down? I'd like to provide more information if it helps because I feel
> it's coming close (after trying one Fedora version after the other) to actually
> being usable on my hardware...
If the problem is with bluetooth its not the same problem as this bug so please file a new bug against the ekiga component, but first review bug 602175 as its related to ekiga and BT as well. This bug is closed. If you are having a problem with ekiga with bluetooth it needs to be filed as another bug otherwise it becomes confusing.
(In reply to comment #35)
> If the problem is with bluetooth its not the same problem as this bug so please
> file a new bug against the ekiga component, but first review bug 602175 as its
> related to ekiga and BT as well. This bug is closed. If you are having a
> problem with ekiga with bluetooth it needs to be filed as another bug otherwise
> it becomes confusing.
No, what I am reporting here is not the bluetooth bug, that's a separate issue. I initially had a situation where what I was seeing coincided _exactly_ with the original bug report. Playing some more, I noticed that (a) the "ALSA Could not write message" in the -d 1 log that the orignal reporter saw could not be reproduced reliably (but I definitely got it initially because I used it in a google seach that led me to this bugzilla entry) and (b) there is a lot of interaction with other audio components. As reported, the presence of a bluetooth headset which is _not_ selected as pulseaudio input or output device did make the problem disappear. It is very hard to test this out, because I have not found a reliable way to make the original problem reappear (working state even survives suspend or reboot, then after a while, audio ceases to work).
So yes, the original problem _is_ there, but at least now with F13 on my hardware, it's much more complex than originally described.
> So yes, the original problem _is_ there, but at least now with F13 on my
> hardware, it's much more complex than originally described.
Different bugs for different issues. This one is closed and I'm confused, if its got nothing to do with BT headsets don't mention them.
(In reply to comment #37)
> > So yes, the original problem _is_ there, but at least now with F13 on my
> > hardware, it's much more complex than originally described.
> Different bugs for different issues. This one is closed and I'm confused, if
> its got nothing to do with BT headsets don't mention them.
I am trying to give as much information as possible. I don't know if there is a connection between these issues (I am not an expert). It is a fact, though, that this bug interacts with other parts of the audio system. I'd be surprised if this is bluetooth specific, I'd guess what I saw is just a symptom of a more general issue.
I am willing to provide information the best I can. The problem is that there is a lot of randomness in what I am seeing (even sometimes the camera on echo test drops out - very rare and not obviously correlated with anything else), where I feel unable to determine if it's a new bug or just a facet of a more general one.