Re: [Ekiga-devel-list] Pulse support and Networking (was Re: Reorganizing things)
- From: Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>
- To: Ekiga development mailing list <ekiga-devel-list gnome org>
- Subject: Re: [Ekiga-devel-list] Pulse support and Networking (was Re: Reorganizing things)
- Date: Wed, 02 Sep 2009 18:55:23 +0200
Dave Allan wrote:
> I hesitate a little to speak here, as I'm not completely versed in the
> issues or the code, but here's a short statement of my experience with
> these two problems on Fedora 10 using the SVN head as of about a week
> ago. The head from this morning crashes when I try to make calls, so I
> can't say if the behavior has changed since then. See the rest of my
> comments inline, below. I would be happy to file bugs against these
> behaviors if that would be helpful, or work with someone familiar with
> the code to troubleshoot them further.
>
> yannick wrote:
>> Peter Robinson a écrit :
>>>> Sorry, it is a bad timefor me as my work is starting again; I'll have
>>>> fewer spare time for 2 or 3 weeks...
>>>>
>>>>> (Except Peter: thanks for the nice words and help offer!)
>>>>>
>>>>> Le lundi 31 août 2009 à 19:58 +0200, Damien Sandras a écrit :
>>>>>> Dear all,
>>>>>>
>>>>>> It appears clearly that since a few months I can dedicate less
>>>>>> time than
>>>>>> before to Ekiga. During the first 5 to 6 years of the project, I was
>>>>>> dedicating all evenings to the project and nearly all week-ends,
>>>>>> fully.
>>>>>>
>>>>>> It is now impossible for me to continue developing at that pace.
>>>>>> If we
>>>>>> organize things in a clever way, I think it will not be a problem. My
>>>>>> intensive work probably hide a few organization problems.
>>>>>>
>>>>>> We now have a few very high quality contributors: they help the
>>>>>> project
>>>>>> move forward will less "devotion" from myself.
>>>>>>
>>>>>> The purpose of this e-mail is to identify the areas where people can
>>>>>> help and how we should work. But before identifying those areas, I
>>>>>> would
>>>>>> stress on the fact that my wish is to release often, but with only a
>>>>>> limited set of new features, that are well-tested. We have seen in
>>>>>> the
>>>>>> past that we had worked on many new features, half-finished, and
>>>>>> that it
>>>>>> was hard to stabilize them before doing a release. I don't want
>>>>>> this to
>>>>>> happen.
>>>> I like this idea too, 3.0 was a pain to release. Beside, network (TCP
>>>> support) and the audio part of Ekiga (e.g. pulse audio) needs some new
>>>> features quickly.
>>> >From a Fedora point of view the two "bugs" I see on a regular basis
>>> are "Audio Problems" (will be fixed mostly by a Pulse Audio plugin set
>>> as the default) and Network issues which are mostly Firewall and NAT
>>> based. I think support for upnp would possibly fix most of those
>>> issues for the average user. The would be the most useful features
>>> from my point of view and the later would probably also help the issue
>>> with ekiga.net "not working" mentioned elsewhere.
>>>
>>
>> I see pulse audio as a good thing for the Linux audio stack; it provide
>> a unified test case of the major features and my hope is to see it
>> improve the situation at the end. (and IMHO it really needs
>> improvements...)
>
> Pulse support in the SVN head as of a week or so ago is only partially
> functional. When I place a call, I hear ekiga generate the ring sound
> until the other end picks up the call. The other end hears only digital
> artifacts (soft blip-blip-blip noises) until I open the pulse audio
> volume control application, at which point the other end hears correct
> audio. Closing the volume control application reverts to digital
> artifacts. Reopening it causes audio to work again. I never hear audio
> from the called party. These behaviors are 100% reproducible.
Could you please use latest svn for audio volume? As for stability, we
know the trunk is not stable, please wait...
>> The network issue is also a complex matter. I agree upnp will improve
>> the situation too. Still it will not be enough for some people. The
>> software we compete with here (skype) is full of workarounds for
>> hardware/network config *hostile* to VoIP. As people with software which
>> do not work are always louder than people where it just work, the
>> situation will still harm ekiga reputation. Beside, the security topic
>> here is quite important and very complex, and this is something skype
>> deals with obscurity. Quite frankly, I doubt if the skype protocol was
>> open, it will be considered as secure... I've started to work on the
>> topic, i.e. how to deal with hardware/setup hostile to VoIP. I've hope
>> to publish a white paper in the coming months (I was full of hope to
>> publish this for the end of august, but I was then busy with user
>> support, bug triaging, packages, etc.). I do not see a good fix for that
>> in the short term. Any help is welcome.
>
> On Fedora 10, I have a machine with several interfaces including a VPN
> interface. I am only intermittently able to register and make calls
> through my SIP server. Checking the box in preferences at:
>
> Edit->Preferences->General->General Settings->Network Settings->Enable
> network detection
>
> seems to have a positive effect, in other words, ekiga seems more likely
> to register and place calls when that box is checked, but it's not 100%
> effective.
>
> If I create a virtual machine on this physical machine, ekiga registers
> and makes calls 100% of the time. Both machines are running F10, fully
> updated. The significant difference is that the VM has only one
> interface, plus loopback, whereas the physical host has 5 interfaces
> plus loopback.
>
> Twinkle registers and places calls reliably from this machine. I don't
> know the twinkle code, either, but since it is FOSS, perhaps it would be
> useful to look at its code to see how it operates in the multi-interface
> case.
Yes, I think we should analyse the cases with several interfaces, there
is a bug report on this
http://bugzilla.gnome.org/show_bug.cgi?id=587504, but this will happen
later, maybe in one month...
--
Eugen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]