Created attachment 705062 [details] ekiga -d 4 while making calls with garbled audio output Description of problem: Outgoing audio is sped up and disconnected. Version-Release number of selected component (if applicable): ekiga-4.0.1-1.fc17.i686 How reproducible: always Steps to Reproduce: 1. upgrade to 4.0.1 2. make outgoing call, e.g. to 500 3. receiver hears weirdness as described below Actual results: Outgoing audio bandwidth number on call screen oscillates between a high and a low number. E.g. normal in 4.0.0 is 8.0, but it oscillates between 16 and 0 in 4.0.1. The frequency of oscillation is different on the two different networks I tested. If you sing a song, like Happy Birthday, the problem is more evident. You hear the song at double speed, like a 33rpm record played at 78, for a second, then silence for a second, lather rinse repeat. The period is faster on the second system I tested. Expected results: Normal audio, like with 4.0.0 Additional info: On my second system test, I verified that 4.0.0 was working normally. Then I upgraded *only* ekiga/ptlib/opal. This eliminates any other OS upgrades being the culprit. I left bad karma while in updates testing, but that didn't seem to stop the release.
If anyone else has this problem, archive the 4.0.0 RPMs - you will need them until this is fixed.
I forgot to set severity HIGH. I should mention that *incoming* audio is just fine (and the bandwidth number is a steady 8.0 as normal).
> I left bad karma while in updates testing, but that didn't seem to stop the > release. A single issue which wasn't an audio issue from what I read and you had different updates that seemed to suggest you weren't even sure it was an audio issue won't necessarily stop a release especially when there's a security issue as well.
I just tested calling ekiga from my cell. In this case, the xmit audio number stays at 2.3 (normal is 8.0). I hear snatches of audio, about 2.3 out of every 8 seconds worth :-)
I don't know where in the audio pipeline the issue is, but it doesn't work after the upgrade, and I eliminated any of the OS upgrades - so it is something in ekiga/ptlib/opal, which were the only packages upgraded on my second testing run.
Stuart, there were some changes related to this in ptlib, opal and ekiga, but they are 99% sure (for ex. I removed a workaround appeared 3.5 years before, I supposed noone has such a system now!) Maybe on your system one of these changes failed. Could are you able to do the following: - uninstall all ptlib, opal and ekiga - build ptlib 2.10.10, opal 3.10.9 and ekiga 4.0.0 and see if it works - if not then ptlib is the culprit - if it works, uninstall opal and ekiga and build opal 3.10.10 and ekiga 4.0.0 and do the same check - finally update ekiga too and do the check - here it should not work ?
(In reply to comment #6) > Stuart, there were some changes related to this in ptlib, opal and ekiga, > but they are 99% sure (for ex. I removed a workaround appeared 3.5 years > before, I supposed noone has such a system now!) Maybe on your system one > of these changes failed. Both my systems (Dell Optiplex 170L and 270) are a lot older than 3.5 years. Systems running linux have an average useful life of 7 years, according to one study I read (vs. 3 for Windows). I would figure on people using systems for at least 7 years when cleaning out work arounds. (And even then, I am still using pre-2000 laptops as print servers...the only commercial printserver that actually works is $300.)
(In reply to comment #7) > (In reply to comment #6) > > Stuart, there were some changes related to this in ptlib, opal and ekiga, > > but they are 99% sure (for ex. I removed a workaround appeared 3.5 years > > before, I supposed noone has such a system now!) Maybe on your system one > > of these changes failed. > > Both my systems (Dell Optiplex 170L and 270) are a lot older than 3.5 years. > Systems running linux have an average useful life of 7 years, according to > one study I read (vs. 3 for Windows). I would figure on people using > systems for at least 7 years when cleaning out work arounds. (And even > then, I am still using pre-2000 laptops as print servers...the only > commercial printserver that actually works is $300.) The point about the 3.5 years is nothing to do with age of computers. A rant about that is completely off topic for this bug report. The was a workaround added 3.5 years ago, he didn't mention the age or what the work around was for. I have a 5 year old netbook that works fine with ekiga. Are you OK to build the packages for the testing?
I will work on it. But I have a new observation. Another kernel update (3.7.9-104) appeared for Fedora 17. I installed it on my office computer (that I broke by upgrading only ekiga). Now ekiga-4.0.1 works again. Will try with my home system shortly. Since upgrading only ekiga broke it at the office, and upgrading to kernel-3.7.6-101 + ekiga-4.0.1 broke it at home, I'm going to guess that: 1) it depends on both kernel and ekiga 2) the ISP at both locations is playing mind games with me 2a) does packet loss trigger some kind of "speed up the sound to catch up" heuristic? 2b) do the XMIT numbers on the call screen represent audio data transmitted, or do they actually reflect audio data received at the other end (via some kind of feed back)?
When I get back to the office (after snowmageddon), I will try booting from the 3.7.6 kernel (that was not working with ekiga-4.0.1) and see if the problem comes back. Similarly if the home system is also fixed by kernel-3.7.9-104.
What audio input/output have you got selected in the preferences?
(In reply to comment #9) > 2) the ISP at both locations is playing mind games with me > 2a) does packet loss trigger some kind of "speed up the sound to catch up" > heuristic? I do not know, I have to look for this information. > 2b) do the XMIT numbers on the call screen represent audio data > transmitted, or do they actually reflect audio data received at the other > end (via some kind of feed back)? It is transmitted. Everything is related to you own machine. The best thing is to check which of ptlib, opal and ekiga introduced this problem, which is related to a kernel upgrade too.
Ok, upgraded my home system to the same as the office. It has the problem! So now I have the same software packages on two different machines - one works (the older machine), the other doesn't. The non-working machine is dual core - but pretty much every modern CPU is multi-core... I did a little research, and "bursty" packet arrival is indeed a big problem for VOIP, and speeding up the audio when a burst of packets arrives after exhausting the jitter buffer is a common heuristic - it normally helps keep you from missing part of the conversation. I am assuming ekiga does this, since I definitely hear it. So my theory now is that ekiga is not the problem directly, but something is causing "bursty" transmission of the UDP packets - probably related to the kernel. Except that the XMIT number alternating between 16.0 and 0.0 does seem to indicate ekiga is complicit in holding back and bursting the packets. I will now work on reverting and upgrading all the components separately, to see which introduces the problem. (Which apparently involves recompiling since the versions are not binary compatible.) This will take a while.
Aha! The system that works with kernel-3.7.9-104 and ekiga-4.0.1 was using Intel audio for ekiga. The broken system was using USB audio. I switched to using Intel audio for ekiga (and put my speakers on the USB). Now ekiga-4.0.1 works with kernel-3.7.9-104. So something in the USB audio driver is bursting the audio data, apparently.
So is this a kernel bug, or an ekiga bug?
To summarize so far: ekiga-4.0.0 with kernel-3.7.6 works with USB audio. Upgrading either the kernel to 3.7.9 or ekiga to 4.0.1 seems to break USB audio, by causing transmitted audio to be bunched into bursts. Ekiga recovers from the bursting by speeding up the audio to catch up (a standard procedure). This would be great if the bursting were occasional, but the bursting happens every second. My guess is that the kernel USB audio driver is holding back on audio data, and gives it to ekiga in larger, but out of date packages. In any case, the work around is to switch to using internal (Intel) audio for ekiga, and the USB audio for external speakers (which use a much larger buffer for playing music and stuff). In light of these latest findings, is it still useful to go through the recompiling to test various ekiga/ptlib/opal version combinations?
As you said that upgrading ekiga alone from .0 to .1 breaks USB, there is something which can be done in ekiga to fix it. If you have time, it would be interested to find out which of ptlib, opal and ekiga broke things. If you do not have time, you can enjoy ekiga, we will wait for another user having the same problem (but it will be more difficult to find out the problem). On the other hand, it could also be a temporary kernel misconfiguration (not too likely however) which when fixed, will make this issue disappear from ekiga too.
I would be interested to know if it changes if you use PulseAudio vs alsa in the ekiga preferences.
(In reply to comment #17) > As you said that upgrading ekiga alone from .0 to .1 breaks USB, there is Not quite. I upgraded ekiga alone on my work system, which was using Intel pci audio for ekiga at the time. This caused a similar problem, but with much smaller period (about 5 dropouts / sec versus one every 2 seconds for USB). The pci audio problem was fixed by upgrading the kernel from 3.7.6 to 3.7.9-104. At home, I had USB audio, and upgraded kernel and ekiga all at once, which broke it. I tried reverting ekiga/ptlib/opal to 4.0.0, and this did not fix it. Reupgrading to 4.0.1 and booting from 3.7.6 kernel did not fix it. Switching from USB to pci audio fixed it. I will definitely try pulse vs. alsa on USB.
Well, it works fine with ALSA and USB. So pulse audio (and some change to USB driver) is the problem. I should have thought of that - pulse audio has been the culprit many times before. (Kicks self.) Should I change the package to pulse? Pursue this further, or just chalk it up to another thing that doesn't work with pulse? Apparently, pulse bunches up the sound data and releases it to the application in 2 sec packages. Not the kind of jitter buffer you want for a phone conversation. Is there something in the pulse API that tunes this?
Good to find it out! I am not expert in pulse, I do not know what to say.
It won't be pulse, it rarely is these days and gives a lot of extra features like bluetooth audio etc, I've never been convinced the ekiga implementation of pulse is that great so it might be worth investigating how it can be improved.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.