Cross-compiling ekiga for win32

[Michael Rickmann]

I forgot to say that we apply the patches from within the Makefile. So
for the patch I sent you would edit the Makefile, look for a line saying
(cd $(EKIGA_DIR)/; git $(GIT_EKIGA_REV) ) and add a line, starting with
a tab !!!, (cd $(EKIGA_DIR)/; patch -p1 <
$(WIN32_DIFF_DIR)/ekiga_helpers.diff ).

Jarmo Pussinen schrieb:

> Michael Rickmann wrote:
>> That Window is absolutely harmless. It is caused by some code in Opal
>> when debug output is selected and should only contain messages from the
>> h264_video_pwplugin_helper.exe. Ekiga's debug output should be contained
>> in a file ekiga-stderr.txt which should appear on your desktop. This
>> change of file location has become necessary because of security
>> features of newer Windows versions. I start Ekiga in debug mode from an
>> extra shortcut symbol with -d 4 added to the command line.
>
> And the promised logs follow.
>
> jarmo
>

That is really bad. I have not tested such a new Win32 Ekiga under real
world conditions as I was working on other aspects introduced into the
code. The jitter buffer errors, the last signs of life in the first two
logs come from Opal which was linked in. My observations are that new
Windows are piling up under Win7 once a connection has been established
or inability to open the sound device when a call is made. Together with
your logs it seems to indicate that the code in the "libgmopal" can not
work properly after "Split ekiga into an exec and helper libs". Could
you build Ekiga before that change was done? To do that edit the Win32
Makefile look for a line starting with GIT_EKIGA_REV and make it read
GIT_EKIGA_REV = reset --hard 4fed510c131. Then test again.
As to the crash on exit, it may have been caused by the same problem but
also others. In general Ekiga seems prone to crashes on exit. This is a
problem of design and may have evolved gradually. In essence, Ekiga
waits until the main thread has terminated and relies on Opal and Ptlib
to destroy part of its objects from the heap. This is really difficult
to debug.
Regards
Michael
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Jarmo Pussinen]

Michael Rickmann wrote:
> I forgot to
> say that we apply the patches from within the Makefile. So for the patch
> I sent you would edit the Makefile, look for a line saying (cd
> $(EKIGA_DIR)/; git $(GIT_EKIGA_REV) ) and add a line, starting with a
> tab !!!, (cd $(EKIGA_DIR)/; patch -p1 <
> $(WIN32_DIFF_DIR)/ekiga_helpers.diff ).
>

This works fine.

> That is really bad. I have not tested such a new Win32 Ekiga under real
> world conditions as I was working on other aspects introduced into the
> code. The jitter buffer errors, the last signs of life in the first two
> logs come from Opal which was linked in. My observations are that new
> Windows are piling up under Win7 once a connection has been established
> or inability to open the sound device when a call is made. Together with
> your logs it seems to indicate that the code in the "libgmopal" can not
> work properly after "Split ekiga into an exec and helper libs". Could
> you build Ekiga before that change was done? To do that edit the Win32
> Makefile look for a line starting with GIT_EKIGA_REV and make it read
> GIT_EKIGA_REV = reset --hard 4fed510c131. Then test again.
> As to the crash on exit, it may have been caused by the same problem but
> also others. In general Ekiga seems prone to crashes on exit. This is a
> problem of design and may have evolved gradually. In essence, Ekiga
> waits until the main thread has terminated and relies on Opal and Ptlib
> to destroy part of its objects from the heap. This is really difficult
> to debug.

Due to connection problems on (remote part I suspect) I had much
time to think about "make update-sources" and made up a local
cache thingy. It can help with this kind of builds quite a much.
I included a patch, if some one else is also interested about that
kind of thing.

My builds took a lot of time, because I tried to use that patch
on this revision also. But I got over it and got it build
eventually.

At first runs I got just error dialog lock ups, when the call was
connected. See error logs.

The error dialogs that kept popping up said that
audio device was opened OK, but reading from it fails.
Many times over and over and over ...
This bug is quite annoying and probably should be fixed also.

Reason seemed to be that audio/video settings were wrong
and probably from that crashing version of ekiga.

After changing those devices no lockups or crashes have
happened in one session and many calls in/out. But due
to my test environment I was happy with completely
silent calls with video only. After a while I noticed
that this was not good.

Then I deleted my ekiga.conf so that I would get
complete clean start. Now I have not got decent
session on at all (and some on exit crashes also).

It seems that, if caller and callee have different sets
of audio (video?) codecs selected it already causes Windows
ekiga to lock up.

I will test more. First I try to get calls throug again
with some settings and then I try to come up with tests,
where only one thing is changed and bad things start to
happen.

jarmo

P.S. My first post of logs got too big and I had to cancel it.
So I sent only this one that I have hevily edited.
I removed millions of lines like:
"2009/07/09 12:43:32.218  1:00.426       Media Patch:3400 GMAudioInputManager_ptlib Encountered
error while trying to read data"

But some other lines have been deleted also. Maybe it is still useful.



_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Jarmo Pussinen]

Jarmo Pussinen wrote:

> Michael Rickmann wrote:
>> That is really bad. I have not tested such a new Win32 Ekiga under real
>> world conditions as I was working on other aspects introduced into the
>> code. The jitter buffer errors, the last signs of life in the first two
>> logs come from Opal which was linked in. My observations are that new
>> Windows are piling up under Win7 once a connection has been established
>> or inability to open the sound device when a call is made. Together with
>> your logs it seems to indicate that the code in the "libgmopal" can not
>> work properly after "Split ekiga into an exec and helper libs". Could
>> you build Ekiga before that change was done? To do that edit the Win32
>> Makefile look for a line starting with GIT_EKIGA_REV and make it read
>> GIT_EKIGA_REV = reset --hard 4fed510c131. Then test again.
>> As to the crash on exit, it may have been caused by the same problem but
>> also others. In general Ekiga seems prone to crashes on exit. This is a
>> problem of design and may have evolved gradually. In essence, Ekiga
>> waits until the main thread has terminated and relies on Opal and Ptlib
>> to destroy part of its objects from the heap. This is really difficult
>> to debug.
>

I run some more simple test cases and put logs and their
short descriptions in the following place:
<http://www.pt-controlnet.fi/ekiga/ekiga-stderr-desc-001-011.zip>

There is a single call (in or out) in each case and only the completely
silent ones worked. I had less time than I anticipated, so there is
only 11 cases.

My vacation starts just about now, so I cannot help you more until later.

jarmo

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list