Bug 481722 - Ekiga audio playback broken
Ekiga audio playback broken
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ekiga (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-27 06:30 EST by Nils Philippsen
Modified: 2010-06-10 18:41 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:42:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
yum.log (33.97 KB, text/plain)
2009-02-21 06:16 EST, Alec Leamas
no flags Details
logfile of ekiga -d 4 (191.19 KB, text/plain)
2009-10-27 08:30 EDT, moon300web
no flags Details
Logfile from ekiga -d 4 (234.16 KB, text/plain)
2010-06-09 04:31 EDT, oliver
no flags Details

  None (edit)
Description Nils Philippsen 2009-01-27 06:30:02 EST
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):
ekiga-3.0.2-1.fc10.x86_64

How reproducible:
Reproducible

Steps to Reproduce:
1. Start ekiga
2. Call "Echo test" (sip:500@ekiga.net)
  
Actual results:
Video is replayed correctly, audio is silent.

Expected results:
Voice explains service, then you hear your own voice or whatever noises are in your room with a slight delay.

Additional info:
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
[...]
Comment 1 Peter Robinson 2009-01-27 06:37:08 EST
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?
Comment 2 Pierre-YvesChibon 2009-01-28 08:30:45 EST
Hi

I am having the same problem on my laptop
$ rpm -q ekiga
ekiga-3.0.2-1.fc10.x86_64

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.
Comment 3 Pierre-YvesChibon 2009-01-28 08:34:16 EST
ahah 

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 :)
Comment 4 Peter Robinson 2009-01-28 19:47:25 EST
There's also an issue with sounds with kernel version 2.6.27.9-159.fc10 see bug https://bugzilla.redhat.com/show_bug.cgi?id=477954 for more details. Nils is this fixed for you as well?
Comment 5 Nils Philippsen 2009-01-29 05:05:18 EST
(In reply to comment #4)
> There's also an issue with sounds with kernel version 2.6.27.9-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
Comment 6 Peter Robinson 2009-02-18 05:21:42 EST
Nils, is this still a problem?
Comment 7 Nils Philippsen 2009-02-18 05:59:39 EST
Unfortunately yes, with these package versions:

sox-14.1.0-5.20081105cvs.fc10.x86_64
libao-0.8.8-5.fc10.x86_64
gsm-1.0.12-6.fc9.x86_64
ekiga-3.0.2-2.fc10.x86_64
opal-3.4.4-4.fc10.x86_64
ptlib-2.4.4-2.fc10.x86_64

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...
Comment 8 Alec Leamas 2009-02-21 06:13:35 EST
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.
Comment 9 Alec Leamas 2009-02-21 06:16:07 EST
Created attachment 332819 [details]
yum.log 

seems that Feb,17 is the bad day
Comment 10 Alec Leamas 2009-02-21 06:21:28 EST
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".
Comment 11 Scott Williams 2009-02-22 21:04:33 EST
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 500@ekiga.net, it crashes X, and I'm back at GDM login screen on my laptop.
Comment 12 Tomas Mraz 2009-03-30 12:52:41 EDT
I see the same problem with ekiga on Intel HDA on Fedora 11 Beta.
Comment 13 Mike Danko 2009-04-18 09:24:12 EDT
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.
Comment 14 Peter Robinson 2009-04-18 09:42:01 EDT
Do you have an ekiga.net account that you can use to test with the echo service?
Comment 15 Mike Danko 2009-04-18 10:27:20 EDT
(In reply to comment #14)
> Do you have an ekiga.net account that you can use to test with the echo
> service?  

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:*7471101301@ekiga.net (Gizmo5 Echo Test)
sip:500@ekiga.net (Ekiga.net Echo Test)

When logged into a third party (sipphone/gizmo) SIP service, I can call:
echo123@proxy01.sipphone.com (Skype Gateway) *WORKS*
*011188888@ekiga.net (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.
Comment 16 Peter Robinson 2009-04-18 13:35:39 EDT
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.
Comment 17 Peter Robinson 2009-05-10 06:15:39 EDT
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.
Comment 18 Spencer Goh 2009-06-15 17:24:13 EDT
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.

lspci output

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 (snippet)
[268]$ modinfo snd-hda-intel
filename:       /lib/modules/2.6.29.4-167.fc11.x86_64/kernel/sound/pci/hda/snd-hda-intel.ko
description:    Intel HDA driver
license:        GPL
srcversion:     91EA725A6F6E7D8895476F1
depends:        snd-pcm,snd-page-alloc,snd,snd-hda-codec
vermagic:       2.6.29.4-167.fc11.x86_64 SMP mod_unload
Comment 19 Peter Robinson 2009-07-21 16:46:23 EDT
You may wish to upgrade to Fedora 11 which has ekiga 3.2.5 which is much improved.
Comment 20 Richard Schwarting 2009-08-04 02:10:30 EDT
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.)
Comment 21 Pierre-YvesChibon 2009-08-04 02:36:44 EDT
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 :-)
Comment 22 Peter Robinson 2009-08-07 11:13:02 EDT
There's a bug for ekiga audio with pulseaudio here. It should be fixed in ekiga 3.2.6 which is due shortly.

https://bugzilla.redhat.com/show_bug.cgi?id=489724
Comment 23 Peter Robinson 2009-08-07 11:15:30 EDT
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.
Comment 24 Alec Leamas 2009-10-20 12:39:30 EDT
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.
Comment 25 moon300web 2009-10-27 08:29:31 EDT
I have a similar problems:

No sound on ekiga echo test service
Looks like the mic does work (input meter shows input)

Versions:
ekiga-3.2.6-1.fc11.i586
Linux 2.6.30.8-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.
Comment 26 moon300web 2009-10-27 08:30:41 EDT
Created attachment 366257 [details]
logfile of ekiga -d 4
Comment 27 Bug Zapper 2009-11-18 04:09:16 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 Bug Zapper 2009-12-18 02:42:22 EST
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.
Comment 29 oliver 2010-06-09 04:30:08 EDT
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

https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/382234
Comment 30 oliver 2010-06-09 04:31:02 EDT
Created attachment 422472 [details]
Logfile from ekiga -d 4
Comment 31 oliver 2010-06-09 06:44:08 EDT
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...

https://bugzilla.redhat.com/show_bug.cgi?id=602175
https://bugzilla.redhat.com/show_bug.cgi?id=474477

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.
Comment 32 oliver 2010-06-10 09:58:07 EDT
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...
Comment 33 Peter Robinson 2010-06-10 13:11:46 EDT
(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.
Comment 34 oliver 2010-06-10 17:25:34 EDT
(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...
Comment 35 Peter Robinson 2010-06-10 17:33:19 EDT
> > 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.
Comment 36 oliver 2010-06-10 18:05:55 EDT
(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.
Comment 37 Peter Robinson 2010-06-10 18:13:34 EDT
> 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.
Comment 38 oliver 2010-06-10 18:41:30 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.