- If none of the items listed or linked to below solves your problem, head over to Debugging Ekiga and send the relevant debug messages (and, in the case of crashes, backtrace) to the mailing list.
Ekiga only displays a part of the real picture in the video window, what can I do?
If your driver doesn't natively support 176x144, Ekiga will try capturing at a larger size, and scale the picture down. The normal behavior of a driver is the following :
- Ekiga asks for 176x144, the driver does not support it
- Consequently the driver reports "FAILED"
- Ekiga asks for 320x240, the driver supports it
- Consequently the driver reports "OK"
- Ekiga captures at 320x240 and resizes to 176x144 which is what it needs
If the picture isn't scaled, please report the problem to us on the mailing list.
My video framerate is slow
On Ekiga 3.0 you can expect up to 30 frames per second if you camera support it. Sometimes you need to configure your webcam driver to get the most out of it.
The pwc Linux driver
To find out whether you're using the pwc driver, run the following command:
lsmod | grep pwc
If the driver is running you should see something like this:
pwc 92224 1 compat_ioctl32 11136 2 uvcvideo,pwc videodev 30720 3 uvcvideo,pwc usbcore 169904 7 uvcvideo,snd_usb_audio,snd_usb_lib,pwc,ehci_hcd,ohci_hcd
If you're using the pwc driver, you can install setpwc and tell it to use 30 frames per second:
setpwc -f 30
I'm testing my audio setup with the Ekiga configuration assistant, and I have problems, what can I do?
You have to analyse the error message given by the configuration assistant:
- The message indicating that the device can't be opened for reading or writing means that there was an error opening the device. If the device could be opened for playing, but that the error message complains that it couldn't be opened for recording, it means that you have full-duplex problems. The solution is to use a different device for playing and recording, or to install ALSA from http://www.alsa-project.org. This article on how to use ALSA may help you. If the first error message to appear mentions that the device can't be opened for playing, it can also mean that you have permissions problem.
- The message indicating that the device could be opened, but that it is impossible to read from or to write to this device means that another program is already using the device, preventing Ekiga from using it. You can check what program is using the device using $ lsof /dev. It can also mean that you have permissions problem.
- If You get error messageboxes on calls by concurrent sounddevice usage of Ekiga with other applications saying that the audiodevices can't be opened, select the "default" device in all Ekiga audio device settings (for the ringer, too), only the "default" device has dmix access defined implicitely in libasound2, manual dmix setup in ~/.asound.rc or /etc/asound.conf is no longer neccessary for the "default" device with newer ALSA version installations, dmix is now enabled by default for cards not supporting multiple audiostream playback, move such old files out of the way first to test. There is a warning from the Twinkle author(s) for using "default" for the microphone, but I cannot confirm such, report to the ALSA user mailinglist if You run into bad sound issues from the mic, use a broad band codec like G711a (ALAW/PCMA) to test to assure it is not a narrow band codec issue and check Your network performance before reporting to ALSA project.
- If you don't get any error message, but that you don't hear yourself with a 5 seconds delay while talking in your microphone, it means that you have full-duplex problems. You can test recording with another tool called rec, if recording with this tool works, but that you don't hear yourself with the 4 seconds delay using the Ekiga configuration assistant, it proves the full-duplex problem. If recording with that tool doesn't work either, then you have to check your installation again, and possibly your cables. Beware of non PC-standard headsets and microphones with dynamic mics build in, most usual PC-soundchips have no circuit to support them, only condenser microphones, You'll need expensive audio professional soundcards or preamp adapters for dynamic mic support, mostly.
- If you don't get any error message, but you don't hear yourself at all, you might be affected by this stereo/mono-recording problem.
I cannot get the sound to work!
Check that your audio subsystem is configured correctly. You can test your actual ALSA configuration using those echo tests:
$ arecord -D plughw:0,0 -c 1 -r 8000 -f S16_LE - | aplay -D plughw:0,0 -c 1 -r 8000 -f S16_LE -
This will test if your sound card can record and play sounds at 8kHz.
$ arecord -D plughw:0,0 -c 1 -r 16000 -f S16_LE - | aplay -D plughw:0,0 -c 1 -r 16000 -f S16_LE -
This will test if your sound card can record and play sounds at 16kHz.
You should be able to hear yourself with a small delay. Be sure to have your sound levels up and capture on.
If the test fails, try running the same command with -c 2 instead of -c 1. If you hear yourself now, this fix might help you.
Choppy sound with Ekiga
From ALSA version 1.0.9, DMIX is enabled by default for soundcards that do not support several channels at the same time. The default configuration of DMIX in ALSA does not necessarily provide good results by default for VoIP applications. The solution is to directly use the soundcard preferences in the 'Audio Settings' or to redefine your "default" soundcard as described above.
Choppy sound when switching desktops or under heavy load
Nothing can be done. We suggest not using DMIX if you experience that problem. If you do not use the 'Default' soundcard in the Audio Settings, then DMIX will not be used.
I do not hear people, but they can hear me, or I can hear people but they don't hear me
The first thing to do is to use the Ekiga configuration assistant, it will help you to test your driver compatibility and to test the robustness of your driver. It will also give you interesting hints to help debugging your problems. Once you are sure that things are working correctly because you have tested your audio setup with the assistant, you can debug further.
The first thing to check is the "General History" (Tools → General History).
- If you are transmitting sound, you should see that Ekiga starts 2 channels, one for transmission, and one for reception. If no channels are opened for audio transmission and reception, it means that you have no common codec with the remote Endpoint. Please report all codec handshake or interop issues to the Ekiga and openh323.org developer mailinglists.
- If audio channels are opened for transmission and reception, ie if there is a common codec, and if you have tested your audio configuration with the Ekiga configuration assistant and that it worked but you have no sound during calls, it means that you or your friend is behind a NAT/PAT router or firewall that drops the audio packets. Check that it is not the case. Also make sure that your friend has a correct audio setup.
FIXME: more infos here about where the problem is (firewall/router -> which side?)
Echo cancellation doesn't work or not O.K. I use the microphone from my webcam and my sound card for audio output.
Echo cancellation will only work if you use the same sound device for in and out audio. e.g. echo cancellation won't work if you use the microphone on your webcam and the output sound from your soundcard (PCI). The reason is that the echo cancellation mechanism needs to sync the in and out sounds and this can't be done properly yet using two different drivers. Please report echo cancellation issues to the Ekiga and openh323.org developer mailing list.
We advice using a headset with condenser microphone builtin for best audio quality, because of room acoustic issues, too.
Freeze when using ALSA
If gdb stack backtrace shows that ekiga is frozen somewhere in ALSA, such as:
#0 0x00007fffea9ef208 in snd_pcm_state@plt () from /usr/lib/libasound.so.2
#0 0x00007fffe7f47300 in PSoundChannelALSA::Write (this=0x7fffe0018d90, buf=0x10b2d44,
#2 0xb5bfcb34 in snd_pcm_writei () from /usr/lib/libasound.so.2
then this might be a bug in ALSA, a case of deadlock in SysV semaphores, see http://mail.gnome.org/archives/ekiga-list/2010-March/msg00006.html (try whether the posted script helps). Ekiga bug report is https://bugzilla.gnome.org/show_bug.cgi?id=593064.
We are told that in order to communicate with a Polycom system, you need to have a public IP address or only some types of NAT.
Cannot call regular phones with some registrars such as Freephonie with ekiga >= 3.3.2
Switch off H264 video codec and call again.
Cannot register to sip.1und1.de or some other registrar with ekiga <= 3.2.x
Some registrars refuse packets containing extra contact addresses (see https://bugzilla.gnome.org/show_bug.cgi?id=618171 for example), even they follow SIP standard. To overcome their limitation, add %limit in your account name (not user name; for ex. call it myAccount%limit).
I reinstalled Linux and I want to import back (migrate) my configuration settings. How?
We assume you have kept the configuration files (the dot files) of your previous home directory. The configuration of Ekiga is found in ~/.gconf/apps/ekiga/ What you need to do is (make sure Ekiga is not running)
$ killall gconfd-2 $ cp -r myoldhome/.gconf/apps/ekiga ~/.gconf/apps/ $ _
Now you can start Ekiga and it will pick up the old configuration.
Explanation: Ekiga stores the configuration in gconf. We need to kill the gconfd service so that when we put the configuration files in ~/.gconf/apps/ekiga, they will be read again. gconfd-2 is started automatically when an application needs configuration option support (such as Ekiga).
I register, but the communication cannot be established
Please start ekiga like this:
$ ekiga -d 4 2>&1 | grep "PDU is likely too large"
and retry the communication which does not work. If you see lines printed, then it is a known problem (Support SIP over TCP), which hopefully will be fixed soon. To workaround this bug, just remove a few unused codecs (such as G726 ones) in Preferences window and retry the communication.
FRITZ!Box Fon users
Issue: The ADSL Router "FRITZ!Box Fon" made by AVM in Germany has a built-in Network address translation (NAT). But this NAT translation does not function reliably for Ekiga because it depends on a random start port number Ekiga chooses from an available range and Ekiga needs more than one open port. Thus the well-known echo test to sip:firstname.lastname@example.org may work or not: You do hear a sound or not. The status bar may indicate returned audio packages or not. You would have to dial again until an echo is heard.
Cure: In Fritz!Box Fon, add to the "List of port forwardings" ("Liste der Portfreigaben") five entries: Open ports 5061-5065 for UDP protocol. This will provide a reliable (two-way) telecommunication line when you call Ekiga.