Red Hat Bugzilla – Bug 508084
twinkle hangs when outgoing call is ringing
Last modified: 2009-07-26 20:02:49 EDT
Description of problem:
If I try to make an outgoing call with twinkle, and the call has to ring (the other party's auto answer is not set), twinkle gets stuck in some kind of loop with the ringing being heard in the headphones continuously, and twinkle needs to be killed. The other party does get the ring, at least, so after I kill and restart twinkle, they can call me back. Fortunately, incoming calls work normally. I suspect it's actually some sound-related component instead of twinkle that's at fault, but I don't know where else to report this.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Call someone who doesn't have auto answer set. (The ekiga echo test won't work, since it's apparently set to auto answer.)
The ringing sound is continuous in the headphones, but twinkle is otherwise unresponsive. It's necessary to kill and restart twinkle.
Should hear rings separated by silence, and twinkle should continue to work normally so the other party can answer.
I held off reporting this since sound is generally messed up in F11, and I thought a bugfix would have come along by now. I see the "Too big adjustment 32" messages reported in bug #498401, but sound is otherwise working more or less normally for me, except for screeching sounds in the headphones when logging in, which has already been reported as a pulseaudio bug (don't remember the number).
Should also have mentioned that 1) I have all updates applied including yesterday's batch, and am running the latest kernel, and 2) when calling the ekiga echo test, the first few words spoken are sometimes repeated (like "you are about you are about you are about an echo test", with the words "to enter" chopped out), and at the end of the call, after pressing the pound key, the last syllable is chopped off. With F10, the echo test worked perfectly.
I just asked my contact to turn on auto answer to see if that makes it possible for me to call him. It didn't. So I don't know why the ekiga echo test works.
The screeching sounds bug was bug #497742 reported against the kernel, not pulseaudio, sorry.
I tried testing twinkle on another F11 machine with different hardware and 32-bit instead of 64, and have exactly the same behavior. So it should be affecting a high percentage of users. Don't know why it hasn't been reported yet.
Odd. I don't see this here at all off hand. :(
I will try and call various places later today and see if I can get it to happen.
Some things to try in the mean time:
1. try stopping twinkle and doing:
from a terminal. Does it work then?
2. Can you try a call where this happens and then attach your ~/.twinke/twinkle.log file?
You may need to edit it to make sure it doesn't contain any phone numbers or other info.
Created attachment 349711 [details]
twinkle.log when making call and it hangs while ringing (killed)
I tried running twinkle via pasuspender and it made no difference. The above attachment was when running twinkle in the usual way. My router is standard port restricted NAT (Westell 327W DSL modem/router). My contact is running Fedora 10.
My father installed F11 on a machine with different hardware, and when he attempts to call me, the same thing happens - continuous ringing, without pause, and he has to kill it. I get notified of the call attempt, but there's no way for us to establish contact between two F11 machines, since one of us has to call the other. This problem can't be too hard to reproduce. We're both using the ekiga.net server.
I just found that the hang can also be generated by simply calling myself, which should make testing simpler as it doesn't require working with a contact.
The hang also happens if I use a gizmo5.com SIP address and call myself while registered only to the Gizmo server. So it doesn't appear to depend on which SIP server one is registered to. I also tried changing the Ring tone device in the Audio settings from the speakers to the headset and that doesn't help either.
I have an extra machine with F11 installed. I tried testing by calling myself on that machine, with the same results. So of the 3 machines with clean F11 installs and completely different hardware that I and my father have tested, all are affected. The only thing they all have in common is that we are both using the same model of C-Media USB headphone set. Any luck in reproducing this problem?
The hang happens with both the Speaker and Microphone devices under System settings/Audio set to the USB headphone set, which is our preferred setup. If I set the Speaker device to the PC's speakers, the hang doesn't happen when I call myself - instead, after answering the incoming call, it says "far end released call", which is probably normal behavior. So to trigger this, make sure the Speaker and Microphone devices are the same (usually a headset).
Sorry for the delay here... I have been swamped of late and my headset broke. ;(
I will try and see if I can track it down any further.
Perhaps the USB headset is the key here somehow. ;(
After applying yesterday's large batch of updates, including kernel-188.8.131.52-213.fc11, and booting into the new kernel, the twinkle hangs on both of my machines are gone. When running the earlier kernel-184.108.40.206-191.fc11, the problem still exists. This means that my father can finally install F11 on his other machine. The latest version of Ekiga also seems to work okay, finally (at least on the Ekiga echo test) so if necessary we could use that, or Skype.
Interesting. So it's looking like it might have been a ALSA or USB kernel bug in that kernel?
There were other possibly related updates associated with ekiga, like opal and ptlib, that twinkle might also use. I don't know if they're relevant, since I applied all updates before testing. Also, this problem existed ever since F11 came out, up until now. So it was in both prior kernels.
ok. So, shall we close this now?
Or is there anything further we can do?
I'll close it in a few days, after my father has installed F11 on his other machine and we've verified that calling works normally in both directions. Thanks.
ok, sounds good. Sorry I couldn't be of much help here, but I am sure glad it works now. ;)
Changing Component to kernel and closing as CURRENTRELEASE. The kernel version that fixes this is kernel-220.127.116.11-213.fc11. My father installed and fully updated F11 and he can make calls without twinkle hanging.