Re: [Ekiga-devel-list] Windows XP: "wave" volume goes to zero when calling



Michael Rickmann wrote:
Eugen Dedu schrieb:
Michael Rickmann wrote:
Dominik schrieb:
Hi Michael,

please note for the second problem: It happens under linux, too. (not as often, but it does)
So it's not a Windows specific problem.

Dominik


Dominik schrieb:
...

2. I have run/made many of echo tests and found strange things out:
When the connection is established
either (most)
- the volume mutes for fractions of a second and then increased to the
saved value.
or (sometimes)
- sound is muted (not visible in windows mixer) and the volume button in
ekiga is greyed out.
or (only a few)
- sound is OK, but the volume button in ekiga is greyed out.
or (only a very few)
- sound is muted (not visible in windows mixer), the volume button in
ekiga is OK, but the first slider is greyed out.

regrads
Dominik

Thank you Dominik. I experience these problems as well. Up to now I was not shure that they were not due to the STUN problems which I have with my Fritz!Box. But now I think that we really have to fix this. I need some help from the real Ekiga experts here. So I uploaded a d4 log to http://wwwuser.gwdg.de/~mrickma/ekiga/xaudiogreyed.tar.gz . It illustrates one of the cases you describe, here a short summary:

One successful call to 500 ekiga net, on the second call button for audio seetings window is greyed, I can hear the intro but not the echo of my voice.

12952: ekiga GMAudioInputManager_ptlib Closing device Plantronics Headset 13052: Media Patch:372 AudioInputCore Falling back to SILENT (Ekiga/Ekiga)

inbetween I fiddled around with the local video button
around here the new call is made

14672: Pool:2612 GMAudioInputManager_null Opening Device SILENT (Ekiga/Ekiga)

Between 13052 and 14672 no attempt is made to set audio input to the Plantronics Headset.

This seems to be http://bugzilla.gnome.org/show_bug.cgi?id=586531.

Hi Eugen, hallo Dominik,
I think, I fixed it, i.e. possibly the connected cases of 586531. The main thread was closing the audioinput device, while the "Media Patch" thread which pumps the data into the internet was still active. Consequently "Media Patch" switched to the silence device. This was left in current_device of audioinput-core.cpp, and it was used for the next call. Attached patch also sets internal_set_manager(desired_device); when the stream is started, i.e. when it is really needed. The patch fixes all my greyed audiobutton problems. Dominik, I just uploaded a new http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.pre6-release.exe . Could you try it, please, and see how many of your issues get solved. The initial mute which you desribe is good one, I think. The lady on 500 ekiga net starts babbling along immediately and what we hear is the time which Ekiga needs to get ready. It is better to dump the buffers than to have audio latency.

This is pushed also.

As your cases, Dominik, are so manyfold I also looked into Ekiga's audiooutput with respect to saving the desired device across calls. In priciple audioautput-core can be affected in the same way as audioinput. But at the moment and for me things go right, i.e. AudioOutputCore::stop() is called twice when a call finishes and thus the desired device is saved for sure. I guess the calls come from Ekiga main and a worker thread. But with threading one always knows best in the end, so I prepared an addional patch (attached ekiga_4outaudiodev). The corresponding download is http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.pre6-release.exe.isitbetter . Does it resolve any remaining issues for you? For me it is not better.


--
Eugen


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]