[Ekiga-devel-list] win32 issues
I just joined back into this list again. I tried to cross compile ekiga
for win32. I was a bit lost what all these branches and tags are meant
for. So I took trunk for ekiga, tag v3_6_1 for opal and tag v2_6_1 for
ptlib. Presumably this is not the place where bug fixing towards an
Ekiga 3.2 for win32 is happening. Could you direct me?
I managed to address some of the win32 build issues which have already
been reported to this list.
1) opal, g722codec.c can not be compiled, as reported by Thierry
Simonnet
http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00082.html .
Preprocessor output indeed shows dllimport functions. This is due to
plugin-config.h not being included as it is e.g. in g726codec.c . See
attached opal_G722dll.diff how one could fix this.
2) ptlib/src/ptlib/common/ptime.cxx issue is due to differences in the
definition of STDAPICALLTYPE in ptime.cxx and getdate.tab.c. At the
level of object files ptime.o was requesting _PTimeParse whereas
getdate.tab.o was providing _ptimepa...@12 . Attached
ptlib_ptime-stdcall.diff lets ptime.cxx use the dll naming scheme, i.e.
_ptimepa...@12
3) Ekiga's ldap support needs libsasl2 as reported by Michael
Cronenworth in
http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00062.html .
This seems a major issue as it may require sasl enabled ldap as well.
cyrus-sasl-2.1.22 can be used in a win32 environment, the Pidgin
developers use it, see
http://developer.pidgin.im/wiki/BuildingWinPidgin#GetthePidginsourcecode . They
even provide binaries compiled with Microsoft tools. So in the Makefile one
could add:
LIBSASL2_VER := 2.1.22
LIBSASL2_DIR := $(BUILDROOT)/cyrus-sasl-$(LIBSASL2_VER)
LIBSASL2_ARCHIVE := cyrus-sasl-$(LIBSASL2_VER).zip
LIBSASL2_URL := http://developer.pidgin.im/static/win32
...
### libsasl2
update-sources::
echo --- Getting libsasl2 ...
$(WGET) -P $(SRCDIR) $(LIBSASL2_URL)/$(LIBSASL2_ARCHIVE)
$(LIBDIR)/libsasl2.a: $(SRCDIR)/$(LIBSASL2_ARCHIVE)
rm -f $(LIBDIR)/libsasl2.a
rm -rf $(LIBSASL2_DIR)
unzip -u $(SRCDIR)/$(LIBSASL2_ARCHIVE) -d $(BUILDROOT)
cp $(LIBSASL2_DIR)/lib/libsasl.lib $(LIBDIR)/libsasl2.a
Fortunately the Mingw Linker seems capable of handling Microsoft .lib
libraries.
I made a preliminary patch to ekiga/configure.ac which allows
configuration --with-libsasl2-dir=$(LIBSASL2_DIR), see attachment. This
allows Ekiga to be compiled with ldap support.
QUESTION ??? Do we have to compile Openldap with sasl support to use it
in Ekiga? Currently the win32 Openldap is configured
--with-cyrus-sasl=no .
I hope this helps a bit getting everything compiled. This seems a
prerequisite for getting things fixed in Ekigas code for win32.
Regards
Michael
diff -ur opal.orig/plugins/audio/G722/g722codec.c opal/plugins/audio/G722/g722codec.c
--- opal.orig/plugins/audio/G722/g722codec.c 2009-03-29 09:03:28.132407340 +0200
+++ opal/plugins/audio/G722/g722codec.c 2009-03-29 08:50:09.520407000 +0200
@@ -24,6 +24,10 @@
* $Date: 2009-01-03 10:24:21 +0100 (Sa, 03. Jan 2009) $
*/
+#ifndef PLUGIN_CODEC_DLL_EXPORTS
+#include "plugin-config.h"
+#endif
+
#include
#include "VoIPCodecs/inttypes.h"
diff -ur opal.orig/plugins/audio/G722/Makefile.in opal/plugins/audio/G722/Makefile.in
--- opal.orig/plugins/audio/G722/Makefile.in 2009-03-29 09:03:28.132407340 +0200
+++ opal/plugins/audio/G722/Makefile.in 2009-03-29 09:00:45.868407000 +0200
@@ -35,6 +35,7 @@
SRCDIR = ./VoIPCodecs
OBJDIR = ./obj
+PLUGINDIR=../..
CC =...@cc@
CXX =...@cxx@
@@ -42,6 +43,7 @@
PLUGINEXT =...@pluginext@
STDCCFLAGS =...@stdccflags@
LDFLAGS =...@ldflags@
+EXTRACFLAGS =-I$(PLUGINDIR)
SRCS += g722codec.c \
$(SRCDIR)/g722_encode.c \
@@ -53,7 +55,7 @@
$(OBJDIR)/%.o : %.c
@mkdir -p $(OBJDIR) >/dev/null 2>&1
- $(CC) -I../../../include $(STDCCFLAGS) $(OPTCCFLAGS) $(CFLAGS) -c $< -o $@
+ $(CC) -I../../../include $(STDCCFLAGS) $(OPTCCFLAGS) $(CFLAGS) $(EXTRACFLAGS) -c $< -o $@
PLUGIN = ./g722_audio_pwplugin.$(PLUGINEXT)
diff -ur ptlib.orig/src/ptlib/common/ptime.cxx ptlib/src/ptlib/common/ptime.cxx
--- ptlib.orig/src/ptlib/common/ptime.cxx 2009-03-29 20:39:41.325934225 +0200
+++ ptlib/src/ptlib/common/ptime.cxx 2009-03-29 20:31:01.416408000 +0200
@@ -545,7 +545,9 @@
extern "C" {
-#ifndef STDAPICALLTYPE
+#ifdef _WIN32
+#define STDAPICALLTYPE __stdcall
+#else
#define STDAPICALLTYPE
#endif
diff -ur ekiga.orig/configure.ac ekiga/configure.ac
--- ekiga.orig/configure.ac 2009-03-29 18:03:09.432404211 +0200
+++ ekiga/configure.ac 2009-03-29 18:02:07.164406000 +0200
@@ -344,7 +344,17 @@
fi
dnl Checking for libsasl2
- AC_CHECK_HEADER(sasl/sasl.h,,AC_MSG_ERROR([*** libsasl2 headers not found]))
+ AC_ARG_WITH(libsasl2-dir, AS_HELP_STRING([--with-libsasl2-dir=PFX],[location of LIBSASL2]), with_libsasl2_dir="$withval", with_libsasl2_dir="/usr")
+
+ dnl Check for the libsasl2 includes presence
+ AC_MSG_CHECKING(for LIBSASL2 includes in ${with_libsasl2_dir}/include/)
+ AC_MSG_RESUL
Re: [Ekiga-devel-list] win32 issues
Ok I have submitted the two bug reports https://sourceforge.net/tracker/?func=detail&aid=2728003&group_id=204472&atid=989748 https://sourceforge.net/tracker/?func=detail&aid=2728037&group_id=204472&atid=989748 Another Win32 issue, the "crash on exit" one: I have been fighting to obtain a debug built of ekiga which allows gdb to backtrace across different dlls. For others who try the same: in the win32 Makefile autogen.sh with --enable-opal-debug instead of --enable-debug and use -gstabs instead of -g as the debugging flag. Attached gdb backtrace was produced on an XP home machine using the gdb contained in https://sourceforge.net/project/downloading.php?group_id=204414&use_mirror=switch&filename=gdbserver-6.8-002-20090131.exe&a=88862589 To me the underlying bug appears obscure. Apparenly, it happens when the sigc++ objects for the address book are destroyed. Can anyone suggest a strategy how to approach this crash? Regards Michael Program received signal SIGSEGV, Segmentation fault. 0xfeeefeee in ?? () (gdb) bt #0 0xfeeefeee in ?? () #1 0x07ef2183 in sigc::internal::slot_rep::disconnect (this=0x86ad470) at functors/slot_base.cc:50 #2 0x07ef21c3 in sigc::internal::slot_rep::notify (data=0x86ad470) at functors/slot_base.cc:63 #3 0x07ef1b51 in sigc::internal::trackable_callback_list::~trackable_callback_list (this=0x86d66b8) at trackable.cc:89 #4 0x07ef1c14 in sigc::trackable::notify_callbacks (this=0x865311c) at trackable.cc:67 #5 0x07ef1c57 in sigc::trackable::~trackable (this=0x865311c) at trackable.cc:51 #6 0x07ef1472 in sigc::signal_base::~signal_base (this=0x865311c) at signal_base.cc:107 #7 0x008ca3de in sigc::signal2, gmref_ptr, sigc::nil>::~signal2 () #8 0x004762bc in Ekiga::ContactCore::~ContactCore (this=0x8653110) at ../../../lib/engine/addressbook/contact-core.cpp:51 #9 0x0093ace0 in GmRefCounted::unreference () #10 0x0092fe1a in gmref_ptr::reset () #11 0x0093039d in gmref_ptr::~gmref_ptr () #12 0x00925825 in __gnu_cxx::new_allocator >::destroy() #13 0x00a086a0 in std::list, std::allocator > >::_M_erase () #14 0x00a0875d in std::list, std::allocator > >::pop_front () #15 0x0043c35f in Ekiga::ServiceCore::~ServiceCore (this=0x8678ee8) at ../../../lib/engine/framework/services.cpp:46 #16 0x00457112 in engine_stop () at engine.cpp:314 #17 0x0042299f in GnomeMeeting::StopEngine (this=0xb3a0d0) at ekiga.cpp:248 #18 0x0040f4b4 in main (argc=2359232, argv=0x40f59f) at gui/main.cpp:4575 (gdb)___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] another two Win32 crashes
I try to get Win32 Ekiga built and running from current SVN HEAD and experienced difficulties in the local rooster and the echo cancellation. 1) The crash when I right click local rooster to add a new contact is due to SVN commit 7830 to local-heap.cpp . When I reverse that patch it works, though any private contacts are only shown as long as Ekiga has not registered. 2) When I try to connect to 5...@ekiga.net with echo cancellation enabled I get a crash. Ekiga shows "Connected with 5...@ekiga.net Call Duration ... PCMA - H261" and I can hear the female voice before a debugger is attached. You can find the logs at http://wwwuser.gwdg.de/~mrickma/ekiga/logs-win32-crashes.tar.gz They are a bit to long for this mail. Surprisingly the echo cancel crash is triggered from speex/libspeex/kiss_fft.c regardless wether I have enabled the speex codec or not. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga.rc
Am Samstag, den 18.04.2009, 14:57 +0200 schrieb Julien Puydt:
> Eugen Dedu a écrit :
> > Is there a way to move ekiga.rc from root to win32?
>
> 1) git mv ekiga.rc win32/
> 2) make sure any file referencing ekiga.rc now searches for it in win32/
>
> Snark
Could you please rename it so that the basename is distinctive, e.g.
ekiga-rc.rc ? I ask this because eventually we can include compilation
of the resources into the autoconf/libtool make process and then an
ekiga.o file would be a bit dangerous I think. Additionally VALUE
"SpecialBuild", CVS_VERSION in the resource file is a bit outdated. Now
an EKIGA_REVISION is defined in src/revision.h . See attached patch as
an example for how one could handle the Win32 resources.
Regards
Michael
diff -urN ekiga.orig/configure.ac ekiga/configure.ac
--- ekiga.orig/configure.ac 2009-04-14 10:46:36.796362971 +0200
+++ ekiga/configure.ac 2009-04-14 10:47:05.264362806 +0200
@@ -100,6 +100,8 @@
;;
mingw* )
+LT_PROG_RC
+
gm_platform="mingw"
CFLAGS="$CFLAGS -DSTATIC_LIBS_USED"
CXXFLAGS="$CXXFLAGS -DSTATIC_LIBS_USED"
diff -urN ekiga.orig/ekiga.rc ekiga/ekiga.rc
--- ekiga.orig/ekiga.rc 2009-04-14 10:44:37.672360584 +0200
+++ ekiga/ekiga.rc 1970-01-01 01:00:00.0 +0100
@@ -1,29 +0,0 @@
-#include "config.h"
-
-1 VERSIONINFO
-FILEVERSION MAJOR_VERSION, MINOR_VERSION, BUILD_NUMBER, 0
-PRODUCTVERSION MAJOR_VERSION, MINOR_VERSION, BUILD_NUMBER, 0
-FILEFLAGSMASK 0
-FILEOS 0x4
-FILETYPE 1
-{
- BLOCK "StringFileInfo"
- {
- BLOCK "040904E4"
- {
- VALUE "CompanyName", "see www.ekiga.org"
- VALUE "FileDescription", "Ekiga is a free Voice over IP phone"
- VALUE "FileVersion", VERSION
- VALUE "InternalName", "Ekiga"
- VALUE "LegalCopyright", "2000-2009 Damien Sandras"
- VALUE "ProductName", "Ekiga"
- VALUE "OriginalFilename", "ekiga.exe"
- VALUE "ProductVersion", PACKAGE_VERSION
-#ifdef CVS_VERSION
- VALUE "SpecialBuild", CVS_VERSION
-#endif
- }
- }
-}
-
-2 ICON DISCARDABLE "win32/ico/ekiga.ico"
diff -urN ekiga.orig/ekiga-rc.rc ekiga/ekiga-rc.rc
--- ekiga.orig/ekiga-rc.rc 1970-01-01 01:00:00.0 +0100
+++ ekiga/ekiga-rc.rc 2009-04-14 10:47:05.268363315 +0200
@@ -0,0 +1,28 @@
+#include "config.h"
+#include "src/revision.h"
+
+1 VERSIONINFO
+FILEVERSION MAJOR_VERSION, MINOR_VERSION, BUILD_NUMBER, 0
+PRODUCTVERSION MAJOR_VERSION, MINOR_VERSION, BUILD_NUMBER, 0
+FILEFLAGSMASK 0
+FILEOS 0x4
+FILETYPE 1
+{
+ BLOCK "StringFileInfo"
+ {
+ BLOCK "040904E4"
+ {
+ VALUE "CompanyName", "see www.ekiga.org"
+ VALUE "FileDescription", "Ekiga is a free Voice over IP phone"
+ VALUE "FileVersion", VERSION
+ VALUE "InternalName", "Ekiga"
+ VALUE "LegalCopyright", "2000-2009 Damien Sandras"
+ VALUE "ProductName", "Ekiga"
+ VALUE "OriginalFilename", "ekiga.exe"
+ VALUE "ProductVersion", PACKAGE_VERSION
+ VALUE "SpecialBuild", EKIGA_REVISION
+ }
+ }
+}
+
+2 ICON DISCARDABLE "win32/ico/ekiga.ico"
diff -urN ekiga.orig/Makefile.am ekiga/Makefile.am
--- ekiga.orig/Makefile.am 2009-04-14 10:46:36.796362971 +0200
+++ ekiga/Makefile.am 2009-04-14 10:47:05.268363315 +0200
@@ -31,7 +31,7 @@
win32/directx/mingw_dshow_port.h\
win32/directx/strmif.h \
win32/directx/uuids.h \
- ekiga.rc \
+ ekiga-rc.rc \
win32/Makefile \
win32/nsisinstaller/ekiga.nsi\
win32/nsisinstaller/language_files/hungarian.nsh \
diff -urN ekiga.orig/src/Makefile.am ekiga/src/Makefile.am
--- ekiga.orig/src/Makefile.am 2009-04-14 10:44:37.049435709 +0200
+++ ekiga/src/Makefile.am 2009-04-14 10:48:39.744363890 +0200
@@ -85,6 +85,12 @@
ekiga.h \
ekiga.cpp
+# resources
+if WIN32
+ekiga_SOURCES += \
+ $(top_srcdir)/ekiga-rc.rc
+endif
+
if HAVE_DBUS
ekiga_SOURCES += \
dbus-helper/dbus.h \
@@ -131,10 +137,13 @@
SVN_REVISION=$(shell head ../.svn/entries -n11 2>/dev/null | tail -n1)
CACHED_REVISION=$(shell cat revision.h 2>/dev/null | cut -c24-)
+.rc.o:
+ $(LIBTOOL) --tag=RC --mode=compile $(RC) $< -o $@ -I $(top_srcdir)
+
src/revision.h:
$(shell if test -e "../.svn/entries"; then \
if test "x$(SVN_REVISION)" != "x$(CACHED_REVISION)"; then \
-echo "#define EKIGA_REVISION $(SVN_REVISION)" > revision.h; \
+echo "#define EKIGA_REVISION \"$(SVN_REVISION)\"" > revision.h; \
fi \
else \
if !(test -e "./revision.h"); then\
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga.rc
Am Samstag, den 18.04.2009, 20:36 +0200 schrieb Julien Puydt: > Michael Rickmann a écrit : > > See attached patch as > > an example for how one could handle the Win32 resources. > > Do you want me to commit that patch? > > Snark First we should decide whether the resources are moved to the win32 subdirectory. With my patch the resources would remain in the base directory. I think that files containing copyright information, as the resources do, could live there. Additionally, my patch is not quite complete as it does not contain the change made to the win32 Makefile - it will need more changes when we have ekiga 3.2 running - where I use RC instead of WINDRES as an exported variable. RC seems to be a commonly accepted abbreviation for a resource compiler. I can provide an updated patch. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Revision 7862 breaks Win32
Windows does not know getpwuid, getuid and the associated header file
entries as introduced by 7862. However, glib-2.0 contains the function
g_get_real_name which works for Windows. Eugen, would something like
attached patch work for Linux too?
Regards
Michael
diff -ur ekiga.orig/src/gui/assistant.cpp ekiga/src/gui/assistant.cpp
--- ekiga.orig/src/gui/assistant.cpp 2009-04-18 22:51:34.271766114 +0200
+++ ekiga/src/gui/assistant.cpp 2009-04-18 13:17:50.833171000 +0200
@@ -53,8 +53,6 @@
#include "audioinput-core.h"
#include "audiooutput-core.h"
#include
-#include // for get user full name
-#include // for get user full name
G_DEFINE_TYPE (EkigaAssistant, ekiga_assistant, GTK_TYPE_ASSISTANT);
@@ -388,25 +386,14 @@
static void
prepare_personal_data_page (EkigaAssistant *assistant)
{
- gchar *full_name;
+ const gchar *full_name;
full_name = gm_conf_get_string (PERSONAL_DATA_KEY "full_name");
- if (!full_name || strlen (full_name) == 0) {
-// set full_name if possible
-struct passwd *pw = getpwuid (getuid ());
-if (pw) {
- // sometimes, the full name contains also office, room number etc.
- // and we need to remove them (take until the first "," char)
- gchar **entry = g_strsplit (pw->pw_gecos, ",", 2);
- full_name = g_strdup (entry[0]);
- g_strfreev (entry);
-}
- }
+ if (!full_name || strlen (full_name) == 0)
+full_name = g_get_real_name ();
gtk_entry_set_text (GTK_ENTRY (assistant->priv->name), full_name);
-
- g_free (full_name);
}
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 build Debian based
The mingw32-runtime provided by Ubuntu (presumably also Debian) is outdated when compared to Fedora packages. Commit 22039 to vfw.cxx in ptlib requires really new Win32 headers. For those who have the same difficulties compiling it as I had, have a look at http://wwwuser.gwdg.de/~mrickma/ekiga/mingwrt/mingw32-runtime_3.15-1_all.deb Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] pwlib.pc in windows
Am Sonntag, den 19.04.2009, 15:01 +0200 schrieb Eugen Dedu: > Hi, > > Is win32/diff/ptlib_pwlib.pc.in still used? > None of the diffs in the win32 subdir is used any longer. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga.rc
Am Sonntag, den 19.04.2009, 18:53 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Samstag, den 18.04.2009, 14:57 +0200 schrieb Julien Puydt: > >> Eugen Dedu a écrit : > >>> Is there a way to move ekiga.rc from root to win32? > >> 1) git mv ekiga.rc win32/ > >> 2) make sure any file referencing ekiga.rc now searches for it in win32/ > >> > >> Snark > > > > Could you please rename it so that the basename is distinctive, e.g. > > ekiga-rc.rc ? I ask this because eventually we can include compilation > > of the resources into the autoconf/libtool make process and then an > > ekiga.o file would be a bit dangerous I think. Additionally VALUE > > "SpecialBuild", CVS_VERSION in the resource file is a bit outdated. Now > > an EKIGA_REVISION is defined in src/revision.h . See attached patch as > > an example for how one could handle the Win32 resources. > > Note that ekiga uses git now, so src/Makefile.am info about revision.h > is obsolete... Is it interesting to resuscitate it? > > -- > Eugen Yes, I have seen that. I am still testing. Would something like #define EKIGA_REVISION "EKIGA_3_2_0-80-g80bf6d3" be acceptable in revisioin.h? It is based on the output of git describe, the 80th revision of tag EKIGA_3_2_0 I guess. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] pwlib.pc in windows
Am Montag, den 20.04.2009, 18:49 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Sonntag, den 19.04.2009, 15:01 +0200 schrieb Eugen Dedu: > >> Hi, > >> > >> Is win32/diff/ptlib_pwlib.pc.in still used? > >> > > None of the diffs in the win32 subdir is used any longer. > > Could win32/diff directory be removed completely? > Yes, I think that Win32 Ekiga will be built without separate configuration files and patches. None of the files in the current diff dir is used for current builds. May be that we will need a patch to make the directx headers temporarily compatible with the configure of ptlib. But I think I can fix that directly. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga.rc
Am Montag, den 20.04.2009, 18:12 +0100 schrieb Peter Robinson: > >> Is there a way to move ekiga.rc from root to win32? > > > > 1) git mv ekiga.rc win32/ > > 2) make sure any file referencing ekiga.rc now searches for it in > > win32/ > > > > Snark > > Could you please rename it so that the basename is distinctive, e.g. > ekiga-rc.rc ? I ask this because eventually we can include compilation > of the resources into the autoconf/libtool make process and then an > ekiga.o file would be a bit dangerous I think. Additionally VALUE > "SpecialBuild", CVS_VERSION in the resource file is a bit outdated. Now > an EKIGA_REVISION is defined in src/revision.h . See attached patch as > an example for how one could handle the Win32 resources. > >>> > >>> Note that ekiga uses git now, so src/Makefile.am info about revision.h is > >>> obsolete... Is it interesting to resuscitate it? > >>> > >>> -- > >>> Eugen > >> > >> Yes, I have seen that. I am still testing. Would something like > >> #define EKIGA_REVISION "EKIGA_3_2_0-80-g80bf6d3" be acceptable in > >> revisioin.h? It is based on the output of git describe, the 80th > >> revision of tag EKIGA_3_2_0 I guess. > > > > For my snapshots, I use only the date in the .deb file name (see > > http://snapshots.ekiga.net/snapshots/debian/). Users can know the version > > (the date) with 'dpkg -l' afterwards. Wouldn't this be sufficient for > > windows snapshots too? (Simpler is better :o)) > > I would personally prefer the git version rather than the date version > as there could be multiple different versions of ekiga on a single day > dependant on the amount of commits. By using the git rev you know > exactly what the build was based upon so it makes it easier from a > debug and recreation of the problem perpective. > > Regards, > Peter I agree, currently it is used for ptracing for linux and windows, gui/main.cpp: PTRACE(1, "Ekiga SVN revision: " << EKIGA_REVISION); To have it in the Windows resources too, is for right clicking on ekiga.exe and have people find the revision under properties. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] pwlib.pc in windows
Am Montag, den 20.04.2009, 19:38 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Montag, den 20.04.2009, 18:49 +0200 schrieb Eugen Dedu: > >> Michael Rickmann wrote: > >>> Am Sonntag, den 19.04.2009, 15:01 +0200 schrieb Eugen Dedu: > >>>> Hi, > >>>> > >>>> Is win32/diff/ptlib_pwlib.pc.in still used? > >>>> > >>> None of the diffs in the win32 subdir is used any longer. > >> Could win32/diff directory be removed completely? > >> > > Yes, I think that Win32 Ekiga will be built without separate > > configuration files and patches. None of the files in the current diff > > dir is used for current builds. May be that we will need a patch to make > > the directx headers temporarily compatible with the configure of ptlib. > > But I think I can fix that directly. > > Michael > > The goal is to have all windows (debian etc.) patches integrated > upstream. If needed, a patch could be put temporarily in win32. > > So I wanted to remove completely win32/diff, but I had just noticed that > the diff directory is used in the win32/Makefile (search for diff, > afterwards DIFF). Are you sure win32/diff can be removed?? > It can be removed, perhaps not now. That will break the Makefile even more - there are lots of dependencies on the unused configuration files. Currently, the Makefile is broken and outdated anyhow. My suggestion is that we wait until Win32 Ekiga 3.2 is usable including VFW, DirectX, provide a new Makefile and remove the diff dir then. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] another two Win32 crashes
Am Mittwoch, den 15.04.2009, 15:50 +0200 schrieb Eugen Dedu: > Damien Sandras wrote: > > Le mercredi 15 avril 2009 à 09:49 +0200, Michael Rickmann a écrit : > >> 2) When I try to connect to 5...@ekiga.net with echo cancellation enabled > >> I get a crash. Ekiga shows "Connected with 5...@ekiga.net Call > >> Duration ... PCMA - H261" and I can hear the female voice before a > >> debugger is attached. You can find the logs at > >> http://wwwuser.gwdg.de/~mrickma/ekiga/logs-win32-crashes.tar.gz > >> They are a bit to long for this mail. Surprisingly the echo cancel crash > >> is triggered from speex/libspeex/kiss_fft.c regardless wether I have > >> enabled the speex codec or not. > > > > That's because we are using SPEEX to cancel echo, even if you are not > > using the speex audio codec, we are still using the internal routines. > > However, that code has been giving crashes here and there. I'm not sure > > we can do anything else than disabling it. > > 1. I see in win32/Makefile:97 that speex is downloaded from Web and that > it is version 1.1.12 which is downloaded. Couldn't we take 1.2rc1 from > the same URL? > > 2. I think there is an error in win32/Makefile:381: > rm -f $(LIBDIR)/_ibspeex.a > should be libspeex instead of _ibspeex, isn't it? > > -- > Eugen To make it short, the crash has disappeared and I do not know why. I could not find any changes in Ekiga's or Opal's GIT/SVN which would directly address this issue. In the meantime I upraded the Mingw runtime and switched to speex 1.2rc1 as Eugene suggested. My ekiga.exe depends on the speex dlls but Opal contains its own speex code which is also used. I think I will investigate later. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga.rc
Am Montag, den 20.04.2009, 21:38 +0100 schrieb Peter Robinson: > On Mon, Apr 20, 2009 at 9:17 PM, Michael Cronenworth wrote: > > Original Message > > Subject: Re: [Ekiga-devel-list] ekiga.rc > > From: Michael Rickmann > > To: Ekiga development mailing list > > Date: 04/20/2009 11:54 AM > > > >> > >> Yes, I have seen that. I am still testing. Would something like > >> #define EKIGA_REVISION "EKIGA_3_2_0-80-g80bf6d3" be acceptable in > >> revisioin.h? It is based on the output of git describe, the 80th > >> revision of tag EKIGA_3_2_0 I guess. > > > > > > You cannot do this. Git does not use revision numbers. It uses a commit > > *hash* for tracking. Don't rely on Git hashes. Define another version number > > and use that.If the tag points to the commit, then only the tag is shown. > > Its not (at least in fedora) used as a version number, but rather as a > tracking bit in builds that aren't final releases to allow tracking of > the exact revision. > > Peter As to git describe, man git-describe says: "Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object and the abbreviated object name of the most recent commit." So there you have your counting of revisions. When I do a git describe this morning it says: EKIGA_3_2_0-83-g44151ba So its the 83th commit to tag EKIGA_3_2_0. 44151ba are the first seven digits of the 40 digit hash of Eugen's commit yesterday evening which I need to identify the commit in "git log". I think that git describe comes closest to the versioning we were used from SVN. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 Ekiga painful
Building Win32 Ekiga from current heads is not straightforward. Ekiga,
Ptlib and Opal seem to have regressed in some aspects.
1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to
fix it with attached patch. There were two major issues: Where does
GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment.
My compiler wants the functions at the end, like device_error_in_main,
be explicitly made members of class GMVideoOutputManager_dx. Otherwise
it would not allow the signals to be inherited.
2) Ekiga with current Ptlib head is unable to detect any audio or video
devices - all silence. This seems to be due to the changes introduced
with "Replaced PWLibStupidLinkerHacks". I had to go back to revision
22442.
3) Opal was also changed because of the "PWLibStupidLinkerHacks" and
depends on the changes in Ptlib. I had also to go back.
Regards
Michael
diff -ur ekiga.orig/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp ekiga/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp
--- ekiga.orig/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp 2009-04-24 21:31:18.654979488 +0200
+++ ekiga/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp 2009-04-24 21:33:13.205008765 +0200
@@ -92,14 +92,14 @@
break;
case Ekiga::VO_MODE_UNSET:
default:
-PTRACE (1, "GMVideoOutputManager_DX\tDisplay variable not set");
+PTRACE (1, "GMVideoOutputManager_dx\tDisplay variable not set");
return;
break;
}
if ( (!local_display_info.widget_info_set) || (!local_display_info.config_info_set)
|| (local_display_info.mode == Ekiga::VO_MODE_UNSET) || (local_display_info.zoom == 0) || (current_frame.zoom == 0)) {
-PTRACE(4, "GMVideoOutputManager_DX\tWidget not yet realized or gconf info not yet set, not opening display");
+PTRACE(4, "GMVideoOutputManager_dx\tWidget not yet realized or gconf info not yet set, not opening display");
return;
}
@@ -109,7 +109,7 @@
switch (current_frame.mode) {
case Ekiga::VO_MODE_LOCAL:
-PTRACE(4, "GMVideoOutputManager_DX\tOpening :VO_MODE_LOCAL display with image of " << current_frame.local_width << "x" << current_frame.local_height);
+PTRACE(4, "GMVideoOutputManager_dx\tOpening :VO_MODE_LOCAL display with image of " << current_frame.local_width << "x" << current_frame.local_height);
dxWindow = new DXWindow();
video_disabled = !dxWindow->Init (local_display_info.hwnd,
local_display_info.x,
@@ -129,7 +129,7 @@
break;
case Ekiga::VO_MODE_REMOTE:
-PTRACE(4, "GMVideoOutputManager_DX\tOpening VO_MODE_REMOTE display with image of " << current_frame.remote_width << "x" << current_frame.remote_height);
+PTRACE(4, "GMVideoOutputManager_dx\tOpening VO_MODE_REMOTE display with image of " << current_frame.remote_width << "x" << current_frame.remote_height);
dxWindow = new DXWindow();
video_disabled = !dxWindow->Init (local_display_info.hwnd,
local_display_info.x,
@@ -151,7 +151,7 @@
case Ekiga::VO_MODE_FULLSCREEN:
case Ekiga::VO_MODE_PIP:
case Ekiga::VO_MODE_PIP_WINDOW:
-PTRACE(4, "GMVideoOutputManager_DX\tOpening display " << current_frame.mode << " with images of "
+PTRACE(4, "GMVideoOutputManager_dx\tOpening display " << current_frame.mode << " with images of "
<< current_frame.local_width << "x" << current_frame.local_height << "(local) and "
<< current_frame.remote_width << "x" << current_frame.remote_height << "(remote)");
dxWindow = new DXWindow();
@@ -184,7 +184,7 @@
return;
break;
}
- PTRACE (4, "GMVideoDisplay_DX\tSetup display " << current_frame.mode << " with zoom value of " << current_frame.zoom );
+ PTRACE (4, "GMVideoOutputManager_dx\tSetup display " << current_frame.mode << " with zoom value of " << current_frame.zoom );
if (local_display_info.on_top && dxWindow)
dxWindow->ToggleOntop ();
@@ -197,11 +197,11 @@
if (video_disabled) {
delete dxWindow;
dxWindow = NULL;
-Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMVideoDisplay_DX::device_error_in_main), Ekiga::VO_ERROR));
+Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMVideoOutputManager_dx::device_error_in_main), Ekiga::VO_ERROR));
}
else {
current_frame.accel = Ekiga::VO_ACCEL_ALL;
-Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMVideoDisplay_DX::device_opened_in_main), current_frame.accel, current_frame.mode, current_frame.zoom, current_frame.both_streams_active));
+Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMVideoOutputManager_dx::device_opened_in_main), current_frame.accel, current_frame.mode, current_frame.zoom, current_frame.both_streams_active));
}
}
@@ -261,14 +261,14 @@
}
void
-size_changed_in_main (unsigned width,
+GMVideoOutputManager_dx::size_changed_in_main (unsigned width,
un
Re: [Ekiga-devel-list] ekiga.rc
Am Sonntag, den 19.04.2009, 09:00 +0200 schrieb Julien Puydt:
> Michael Rickmann a écrit :
> > First we should decide whether the resources are moved to the win32
> > subdirectory. With my patch the resources would remain in the base
> > directory. I think that files containing copyright information, as the
> > resources do, could live there. Additionally, my patch is not quite
> > complete as it does not contain the change made to the win32 Makefile -
> > it will need more changes when we have ekiga 3.2 running - where I use
> > RC instead of WINDRES as an exported variable. RC seems to be a commonly
> > accepted abbreviation for a resource compiler. I can provide an updated
> > patch.
>
> It's win32-specific, so indeed it would be nice to push it into win32/.
>
> Ping us back when you have something you're happy with.
>
> Thanks.
>
> Snark
It took me some time to come up with something satisfying. Actually
there are two patches which I use now, a minor one for cleaning up
Ekiga's config files and then the ekiga.rc patch.
The first diff corrects my own mistake. The libsasl2 includes have to be
added to the ldap ones and must not replace them. Additionally it
removes no longer used Win32 config files from WIN32_DIST.
The second diff deals with the Windows resources. They are called now
ekiga-rc.rc and are moved to the win32 subdir. The more distinct name is
necessary because I have integrated them into the autoconf / libtool
build process. ekiga-rc.rc uses now EKIGA_REVISION as defined in
src/revision.h instead of the ancient CVS_VERSION. Since Gnome changed
to git I had to replace SVN_REVISION in src/Makefile.am. I have chosen
the output of git-describe which is in the form
EKIGA_3_2_0-101-g86ade0b, i.e. the 101st commit to tag EKIGA_3_2_0,
where the hash of the commit starts with 86ade0b. This definition of
EKIGA_REVISION will affect ptrace output of linux too. You can change it
to something more appropriate as long as it is quoted.
Regards
Michael
diff -ur ekiga.orig/configure.ac ekiga/configure.ac
--- ekiga.orig/configure.ac 2009-04-12 12:42:55.508570601 +0200
+++ ekiga/configure.ac 2009-04-12 13:16:53.096524000 +0200
@@ -351,7 +351,7 @@
AC_MSG_RESULT()
if test -f ${with_libsasl2_dir}/include/sasl/sasl.h; then
- LDAP_CFLAGS="-I${with_libsasl2_dir}/include"
+ LDAP_CFLAGS="${LDAP_CFLAGS} -I${with_libsasl2_dir}/include"
else
AC_MSG_ERROR(*** libsasl2 headers not found)
fi
diff -ur ekiga.orig/Makefile.am ekiga/Makefile.am
--- ekiga.orig/Makefile.am 2009-04-12 12:42:55.508570601 +0200
+++ ekiga/Makefile.am 2009-04-12 13:17:42.672524000 +0200
@@ -21,13 +21,6 @@
WIN32_DIST = \
win32/ico/ekiga.ico \
win32/ico/ekiga-uninstall.ico\
- win32/diff/opal_opal.pc.in\
- win32/diff/ptlib_Makefile.am\
-win32/diff/ptlib_ptlib.pc.in\
- win32/diff/opal_configure.ac\
- win32/diff/opal_Makefile.am\
- win32/diff/ptlib_configure.ac\
- win32/diff/ptlib_pwlib.pc.in\
win32/directx/Amvideo.h \
win32/directx/control.h \
win32/directx/ddraw.h \
diff -urN ekiga.orig/configure.ac ekiga/configure.ac
--- ekiga.orig/configure.ac 2009-04-26 12:57:19.923585067 +0200
+++ ekiga/configure.ac 2009-04-26 12:57:40.999587765 +0200
@@ -100,6 +100,8 @@
;;
mingw* )
+LT_PROG_RC
+
gm_platform="mingw"
CFLAGS="$CFLAGS -DSTATIC_LIBS_USED"
CXXFLAGS="$CXXFLAGS -DSTATIC_LIBS_USED"
diff -urN ekiga.orig/ekiga.rc ekiga/ekiga.rc
--- ekiga.orig/ekiga.rc 2009-04-26 12:55:34.415613661 +0200
+++ ekiga/ekiga.rc 1970-01-01 01:00:00.0 +0100
@@ -1,29 +0,0 @@
-#include "config.h"
-
-1 VERSIONINFO
-FILEVERSION MAJOR_VERSION, MINOR_VERSION, BUILD_NUMBER, 0
-PRODUCTVERSION MAJOR_VERSION, MINOR_VERSION, BUILD_NUMBER, 0
-FILEFLAGSMASK 0
-FILEOS 0x4
-FILETYPE 1
-{
- BLOCK "StringFileInfo"
- {
- BLOCK "040904E4"
- {
- VALUE "CompanyName", "see www.ekiga.org"
- VALUE "FileDescription", "Ekiga is a free Voice over IP phone"
- VALUE "FileVersion", VERSION
- VALUE "InternalName", "Ekiga"
- VALUE "LegalCopyright", "2000-2009 Damien Sandras"
- VALUE "ProductName", "Ekiga"
- VALUE "OriginalFilename", "ekiga.exe"
- VALUE "ProductVersion", PACKAGE_VERSION
-#ifdef CVS_VERSION
- VALUE "SpecialBuild", CVS_VERSION
-#endif
- }
- }
-}
-
-2 ICON DISCARDABLE "win32/ico/ekiga.ico"
diff -urN ekiga.orig/Makefile.am ekiga/Makefile.am
--- ekiga.orig/Makefile.am 2009-04-26 12:57:19.923585067 +0200
+++ ekiga/Makefile.am 2009-04-26 12:57:41.003585760 +0200
@@ -31,7 +31,7 @@
[Ekiga-devel-list] Win32 DirectX
Ekiga SVN commit 7653 seems not complete. It is apparently based on a discussion on this list in February: http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html . At the moment I work with Ubuntu Intrepid on git master and get circular inclusion of uuids.h and ksuuids.h which will make the ptlib configure fail for DirectX. Attached diff corrects this. An alternative to tweaking DirectX headers may be to use them as they are ment to be used, i.e. preincluding mingw_dshow_port.h, and change ptlib.m4 accordingly. Regards Michael diff -ur ekiga.orig/win32/directx/uuids.h ekiga/win32/directx/uuids.h --- ekiga.orig/win32/directx/uuids.h 2009-04-25 18:22:19.486804883 +0200 +++ ekiga/win32/directx/uuids.h 2009-04-25 18:47:31.934780100 +0200 @@ -18,6 +18,9 @@ // including this file. See wxdebug.cpp in sdk\classes\base. // +#ifndef __UUIDS_INCLUDED__ +#define __UUIDS_INCLUDED__ + #ifndef OUR_GUID_ENTRY #define OUR_GUID_ENTRY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8); @@ -1517,3 +1520,5 @@ #endif // __ENCODER_API_GUIDS__ #undef OUR_GUID_ENTRY + +#endif // __UUIDS_INCLUDED__ ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 DirectX
Am Sonntag, den 26.04.2009, 15:31 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Ekiga SVN commit 7653 seems not complete. It is apparently based on a > > discussion on this list in February: > > http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html > > . At the moment I work with Ubuntu Intrepid on git master and get circular > > inclusion of uuids.h and ksuuids.h which will make the ptlib configure fail > > for DirectX. Attached diff corrects this. An alternative to tweaking > > DirectX headers may be to use them as they are ment to be used, i.e. > > preincluding mingw_dshow_port.h, and change ptlib.m4 accordingly. > > Is your patch to be included in branch too? Because 7653 was not > committed to branch (it seems). > I am not familiar with these branches. When I use the git repository browser for gnome-2-26 I can find the entry 2009-02-11 Fixed mingw32 ... . And also the circular dependency inclusion. So the branch needs fixing too I think. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 DirectX
Am Sonntag, den 26.04.2009, 17:00 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Sonntag, den 26.04.2009, 15:31 +0200 schrieb Eugen Dedu: > >> Michael Rickmann wrote: > >>> Ekiga SVN commit 7653 seems not complete. It is apparently based on a > >>> discussion on this list in February: > >>> http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html > >>> . At the moment I work with Ubuntu Intrepid on git master and get > >>> circular inclusion of uuids.h and ksuuids.h which will make the ptlib > >>> configure fail for DirectX. Attached diff corrects this. An alternative > >>> to tweaking DirectX headers may be to use them as they are ment to be > >>> used, i.e. preincluding mingw_dshow_port.h, and change ptlib.m4 > >>> accordingly. > >> Is your patch to be included in branch too? Because 7653 was not > >> committed to branch (it seems). > >> > > I am not familiar with these branches. When I use the git repository > > browser for gnome-2-26 I can find the entry 2009-02-11 Fixed > > mingw32 ... . And also the circular dependency inclusion. So the branch > > needs fixing too I think. > > Searching through the web interface of git.gnome.org searches through > all the branches. The entry you found is the entry for trunk. > > Let's just wait a bit, we will need anyway to apply many other fixes > from trunk to branch... > I can find the culprit in http://svn.gnome.org/viewvc/ekiga/branches/gnome-2-26/win32/directx/ksuuids.h?r1=6838&r2=7653 too. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga.rc
Am Sonntag, den 26.04.2009, 15:50 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Sonntag, den 19.04.2009, 09:00 +0200 schrieb Julien Puydt: > >> Michael Rickmann a écrit : > >>> First we should decide whether the resources are moved to the win32 > >>> subdirectory. With my patch the resources would remain in the base > >>> directory. I think that files containing copyright information, as the > >>> resources do, could live there. Additionally, my patch is not quite > >>> complete as it does not contain the change made to the win32 Makefile - > >>> it will need more changes when we have ekiga 3.2 running - where I use > >>> RC instead of WINDRES as an exported variable. RC seems to be a commonly > >>> accepted abbreviation for a resource compiler. I can provide an updated > >>> patch. > >> It's win32-specific, so indeed it would be nice to push it into win32/. > >> > >> Ping us back when you have something you're happy with. > >> > >> Thanks. > >> > >> Snark > > > > It took me some time to come up with something satisfying. Actually > > there are two patches which I use now, a minor one for cleaning up > > Ekiga's config files and then the ekiga.rc patch. > > The patches are for trunk only or for gnome-2-26 branch too? > (Personnally, trunk only is ok for me too.) Trunk only is fine for me, but Snark has already acted. > > > The first diff corrects my own mistake. The libsasl2 includes have to be > > added to the ldap ones and must not replace them. Additionally it > > removes no longer used Win32 config files from WIN32_DIST. > > They should be removed from win32/Makefile too, isn't it? Yes, but later as we discussed, because it will break the Makefile completely. Cleaning up the config files will have no adverse effect. > > > The second diff deals with the Windows resources. They are called now > > ekiga-rc.rc and are moved to the win32 subdir. The more distinct name is > > necessary because I have integrated them into the autoconf / libtool > > build process. ekiga-rc.rc uses now EKIGA_REVISION as defined in > > src/revision.h instead of the ancient CVS_VERSION. Since Gnome changed > > to git I had to replace SVN_REVISION in src/Makefile.am. I have chosen > > the output of git-describe which is in the form > > EKIGA_3_2_0-101-g86ade0b, i.e. the 101st commit to tag EKIGA_3_2_0, > > where the hash of the commit starts with 86ade0b. This definition of > > EKIGA_REVISION will affect ptrace output of linux too. You can change it > > to something more appropriate as long as it is quoted. > > I would like to change: > + VALUE "FileDescription", "Ekiga is a free Voice over IP phone" > to > + VALUE "FileDescription", "Ekiga is a free Voice and Video over IP phone" I like it short: "Ekiga is free Voice and Video over IP" , meaning its free and adds video to plain VOIP. We can think about it and change it later. > but phone is not good, what can we put instead? > > (By the way, the desktop description should be changed too: "_Name=Ekiga > Softphone" to what?) Just found it in the .po files, no idea. > > -- > Eugen Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Am Donnerstag, den 30.04.2009, 17:38 +0200 schrieb Julien Puydt: > Michael Cronenworth a écrit : > > Craig Southeren wrote: > >> Last time I tried the procedure at the following URL, it didn't even > >> go close to working on Fedora: > >> > >> http://wiki.ekiga.org/index.php/Cross-compile_Win32 > >> > >> Is that this what you did? Were any changes needed? > > > > The Makefile in Gnome SVN/Git is not appropriate for Fedora MinGW. It > > was made by a guy using Debian. I was not sure how to handle a Fedora > > Makefile, but I think I will just submit it as "Makefile.fedora" and > > call it a day. Let me change it to use Gnome Git instead of SVN and I'll > > post it on this list. > > Would it be possible to merge them into a single Makefile? > > Snark Yes, I think the differences are simple - I had the Fedora packages installed through Debian alien export DEB_BUILD_GNU_TYPE:=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) is not in Fedora export DEB_HOST_GNU_TYPE:="i586-pc-mingw32" HOST_TOOL_PREFIX:=i586-mingw32msvc are different in Fedora One could use simply use: which fedora-one dpkg-architecture as a test. For me that command returns /usr/bin/dpkg-architecture and /usr/bin/dpkg-architecture returns i486-linux-gnu . Depending on the outcome one could adjust all three. As to the stuck linker bug: I am just working on it. Something seems fishy with the macros at the end of include/ptlib/plugin.h . Possibly they are only for MSVC and we should use the "USE_GCC" mechanism for __MINGW32__. Using slightly changed ones in a separate source file to Ekiga gives some hope: i586-mingw32msvc-nm ekiga/src/.libs/ekiga.exe | grep WindowsMultimedia 00a283e0 d .data $_ZGVZN52PPlugin_PSoundChannel_WindowsMultimedia_RegistrationC1EP14PPluginManagerE7factory 00a29e50 d .data $_ZZN52PPlugin_PSoundChannel_WindowsMultimedia_RegistrationC1EP14PPluginManagerE7factory 008bd37c t .text $_ZN52PPlugin_PSoundChannel_WindowsMultimedia_RegistrationC1EP14PPluginManager 00afb398 B _PPlugin_PSoundChannel_WindowsMultimedia_Registration_Instance 00a24a30 D more for PVideoInputDevice_DirectShow and VideoInputDevice_VideoForWindows I did not get that with the original Ptlib macros, it was zero output. Give me a bit more time. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 + Git + cross compiling errors
Am Mittwoch, den 29.04.2009, 11:35 +0200 schrieb Thierry Simonnet: > Hi, > > I'm just back to my office after several weeks and I saw that a lot of > things have changed. > I modified Makefile to handle git, gtk2.16, opal/trunk, ptlib/trunk > (in attachment). > I tried to compile Ekiga for win32 using Debian Lenny 32b and 64b. Here > are the outputs : > > 32b : > i586-mingw32msvc-g++ -mms-bitfields -Os -I/root/win32/include > -march=pentium-mmx -DPTRACING -Wall -Wextra -Winit-self .snip > -I/root/win32/opal/include -c /root/win32/opal/src/opal/recording.cxx -o > /root/win32/opal/lib_mingw_x86/obj/recording.o > /root/win32/opal/src/opal/recording.cxx:198: warning: ignoring #pragma > comment > /root/win32/opal/src/opal/recording.cxx:246: error: extra qualification > 'OpalAVIRecordManager::' on member 'IsResultError' > make[1]: *** [/root/win32/opal/lib_mingw_x86/obj/recording.o] Error 1 > make[1]: Leaving directory `/root/win32/opal' > make: *** [/root/win32/lib/libopal_s.a] Error 2 > > > 64b: > i586-mingw32msvc-gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I"/root/win32/ffmpeg" > -I/root/win32/include -march=pentium-mmx -DPTRACING -fomit-frame-pointer .snip > warning: this is thelocation of the previous definition > vfwcap.c:46: error: redefinition of 'struct videohdr_tag' > vfwcap.c:81: error: conflicting types for 'CAPTUREPARMS' > /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/vfw.h:698: > > error: previous declaration of 'CAPTUREPARMS' was here > make[1]: *** [vfwcap.o] Error 1 > make[1]: Leaving directory `/root/win32/ffmpeg/libavdevice' > make: *** [/root/win32/bin/avcodec.dll] Error 2 > > > Any hints? .snip The 32b : Opal error has not struck me (yet?), but the 64b: ffmpeg one. Have you applied any patch to ffmpeg? The ffmpeg revision 14200 you are using is quite old and only works with old Win32 headers. I currently use 17504 - it helped me porting from Debian Multimedia to Ubuntu. With that version you need recent Win32 headers. You can copy them where the old ones are or use my Mingw runtime package. http://wwwuser.gwdg.de/~mrickma/ekiga/mingwrt/mingw32-runtime_3.15-1_all.deb And add --disable-ffmpeg --disable-ffplay to confffmpeg: in your Makefile. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Warning for revision.h
Am Donnerstag, den 30.04.2009, 16:41 +0200 schrieb Eugen Dedu: > Hi, > > After the update of revision.h I receive the following wraning: > Making install in src > /bin/sh: line 0: cd: ../.git: No such file or directory > fatal: Not a git repository (or any of the parent directories): .git > /bin/sh: line 0: cd: ../.git: No such file or directory > fatal: Not a git repository (or any of the parent directories): .git > make[2]: Entering directory > `/home/dedu/softs/ekiga/toto/ekiga-3.2.0+git20090430.81e65f/src' > /usr/bin/make install-am > /bin/sh: line 0: cd: ../.git: No such file or directory > fatal: Not a git repository (or any of the parent directories): .git > /bin/sh: line 0: cd: ../.git: No such file or directory > fatal: Not a git repository (or any of the parent directories): .git > make[3]: Entering directory > `/home/dedu/softs/ekiga/toto/ekiga-3.2.0+git20090430.81e65f/src' > /bin/sh: line 0: cd: ../.git: No such file or directory > fatal: Not a git repository (or any of the parent directories): .git > /bin/sh: line 0: cd: ../.git: No such file or directory > fatal: Not a git repository (or any of the parent directories): .git > make[4]: Entering directory > `/home/dedu/softs/ekiga/toto/ekiga-3.2.0+git20090430.81e65f/src' > > This is because cd ../.git is always executed in src/Makefile.am: > GIT_REVISION=\"$(shell (cd ../.git; git describe ))\" > CACHED_REVISION=$(shell cat revision.h 2>/dev/null | cut -c24-) > > There should be an if before the "cd"... > Sorry, I did not recognize that the $(shell ) constructs are executed each time a Makefile is read. Could you test attached patch? It seems allright for me. Regards Michael diff -ur ekiga.orig/src/Makefile.am ekiga/src/Makefile.am --- ekiga.orig/src/Makefile.am 2009-05-01 07:54:03.643040332 +0200 +++ ekiga/src/Makefile.am 2009-05-01 07:56:10.011040557 +0200 @@ -137,11 +137,11 @@ .rc.o: $(LIBTOOL) --tag=RC --mode=compile $(RC) $< -o $@ -I $(top_srcdir) -GIT_REVISION=\"$(shell (cd ../.git; git describe ))\" -CACHED_REVISION=$(shell cat revision.h 2>/dev/null | cut -c24-) +GIT_REVISION=\"$$(cd ../.git; git describe )\" +CACHED_REVISION=$$(cat revision.h 2>/dev/null | cut -c24-) src/revision.h: -$(shell if test -d "../.git" -a -n "$$(which git)"; then \ + if test -d "../.git" -a -n "$$(which git)"; then \ if test "x$(GIT_REVISION)" != "x$(CACHED_REVISION)"; then \ echo "#define EKIGA_REVISION $(GIT_REVISION)" > revision.h; \ fi \ @@ -149,7 +149,7 @@ if !(test -e "./revision.h"); then\ echo "#define EKIGA_REVISION \"unknown\"" > revision.h; \ fi \ -fi) +fi AM_CXXFLAGS = $(GTK_CFLAGS) $(GLIB_CFLAGS) $(GNOME_CFLAGS) $(DBUS_CFLAGS) $(BONOBO_CFLAGS) $(OPAL_CFLAGS) $(PTLIB_CFLAGS) $(SIGC_CFLAGS) $(XML_CFLAGS) $(NOTIFY_CFLAGS) AM_LIBS = $(GTK_LIBS) $(GLIB_LIBS) $(GNOME_LIBS) $(DBUS_LIBS) $(BONOBO_LIBS) $(OPAL_LIBS) $(PTLIB_LIBS) $(SIGC_LIBS) $(XML_LIBS) $(NOTIFY_LIBS) ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Am Donnerstag, den 30.04.2009, 11:53 +1000 schrieb Craig Southeren: > Eugen Dedu wrote: > > ..deleted > > > > > We are stuck with this bug, because upstream does not help. What can we > > do...? > > If upstream means Opal, then I think this is being a bit unfair. > > I use Opal/PTLib on Windows and Linux every day. On both these operating > systems, there is no problem. > > We are extremely busy maintaining support for these two operating > systems using their native compilers (gcc and MSVC), as well as bringing > in new code and features. > > I've tried to cross-compile Ekiga for Windows, but it requires a debian > box with the latest dev code (Sid?) and I simply can't dedicate a whole > machine for this purpose, northe time it would take to make it work. > > Now, if I could cross-compile ekiga on a Fedora box then I would be > REALLY interested. :) > > Craig My contribution seems to fit in here: Good news devices are back in Ekiga. Please correct me if I am wrong. Win32 Ekiga uses ptlib plugins statically linked. However, current Ekiga code relies on dynamic plugins or every static plugin being automatically linked in. E.g. Ekiga knows about PVideoInputDevice but not about VideoForWindows. After replacement of the PWLibStupidLinkerHacks in ptlib the linker has no hint that Ekiga wants VideoForWindows and alike. So I would suggest a Win32 specific file which picks up the global consts offered by ptlib as needed - see attached patch. I had to change the macro from include/ptlib/plugin.h because Mingw32 would only do right with "const * somevar" and not with "* const somevar". I guess that that could be changed in ptlib. What do you think about this kind of solution. Regards Michael diff -urN ekiga.orig/src/Makefile.am ekiga/src/Makefile.am --- ekiga.orig/src/Makefile.am 2009-05-01 09:22:30.635647211 +0200 +++ ekiga/src/Makefile.am 2009-05-01 09:26:36.791042703 +0200 @@ -87,7 +87,8 @@ # resources if WIN32 -ekiga_SOURCES += \ +ekiga_SOURCES += \ + $(top_srcdir)/win32/plugin-gconst.cpp \ $(top_srcdir)/win32/ekiga-rc.rc endif diff -urN ekiga.orig/win32/plugin-gconst.cpp ekiga/win32/plugin-gconst.cpp --- ekiga.orig/win32/plugin-gconst.cpp 1970-01-01 01:00:00.0 +0100 +++ ekiga/win32/plugin-gconst.cpp 2009-05-01 09:19:20.607042000 +0200 @@ -0,0 +1,19 @@ +#define PPLUGIN_STATIC_LOAD(serviceName, serviceType) \ + class PPlugin_##serviceType##_##serviceName##_Registration; \ + extern PPlugin_##serviceType##_##serviceName##_Registration PPlugin_##serviceType##_##serviceName##_Registration_Instance; \ + PPlugin_##serviceType##_##serviceName##_Registration const *PPlugin_##serviceType##_##serviceName##_Registration_Static_Library_Loader = &PPlugin_##serviceType##_##serviceName##_Registration_Instance; + +#include "ptbuildopts.h" + +#if P_AUDIO + PPLUGIN_STATIC_LOAD(WindowsMultimedia, PSoundChannel); +#endif + +#if P_DIRECTSHOW + PPLUGIN_STATIC_LOAD(DirectShow, PVideoInputDevice); +#endif + +#if P_VFW_CAPTURE + PPLUGIN_STATIC_LOAD(VideoForWindows, PVideoInputDevice); +#endif + ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 + Git + cross compiling errors
Am Mittwoch, den 29.04.2009, 11:35 +0200 schrieb Thierry Simonnet: > Hi, > > I'm just back to my office after several weeks and I saw that a lot of > things have changed. > I modified Makefile to handle git, gtk2.16, opal/trunk, ptlib/trunk > (in attachment). > I tried to compile Ekiga for win32 using Debian Lenny 32b and 64b. Here > are the outputs : > > 32b : snip > -I/root/win32/opal/include -c /root/win32/opal/src/opal/recording.cxx -o > /root/win32/opal/lib_mingw_x86/obj/recording.o > /root/win32/opal/src/opal/recording.cxx:198: warning: ignoring #pragma > comment > /root/win32/opal/src/opal/recording.cxx:246: error: extra qualification > 'OpalAVIRecordManager::' on member 'IsResultError' > make[1]: *** [/root/win32/opal/lib_mingw_x86/obj/recording.o] Error 1 > make[1]: Leaving directory `/root/win32/opal' > make: *** [/root/win32/lib/libopal_s.a] Error 2 > I too got hit by that one and filed a bug report: https://sourceforge.net/tracker/?func=detail&aid=2785005&group_id=204472&atid=989748 there you can read how to fight through by hand. Or you may consider to go back to revision 22478, i.e. before the AVi file recording was introduced. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] windows stable branch
Am Freitag, den 08.05.2009, 13:41 +0200 schrieb Eugen Dedu: > Hi, > > Windows build is currently delayed by a few bugs. Couldn't we just > create a windows build from the stable branch? Are there modifications > to be done or is it as simple as just build the branch instead of the trunk? > I can try during weekend. What is the stable branch - the tar ball ekiga 3.2 ? My patches to build ekiga master with device detection you find in http://mail.gnome.org/archives/ekiga-devel-list/2009-May/msg3.html http://sourceforge.net/tracker/?func=detail&aid=2785005&group_id=204472&atid=989748 Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] windows stable branch
Am Freitag, den 08.05.2009, 08:54 -0500 schrieb Michael Cronenworth: > Original Message > Subject: [Ekiga-devel-list] windows stable branch > From: Eugen Dedu > To: Ekiga mailing list > Date: 05/08/2009 06:41 AM > > > Hi, > > > > Windows build is currently delayed by a few bugs. Couldn't we just > > create a windows build from the stable branch? Are there modifications > > to be done or is it as simple as just build the branch instead of the > > trunk? > > > > 3.2.0 is "stable," correct? Have the registration STUN issues or > close-on-exit bugs been resolved? If not, there is no point in making a > Win32 build. > STUN is resolved but not in 3.2.0 I think, crash on exit persists. That one seems really difficult. Regards Michael R. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] windows stable branch
Am Freitag, den 08.05.2009, 17:40 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Freitag, den 08.05.2009, 13:41 +0200 schrieb Eugen Dedu: > >> Hi, > >> > >> Windows build is currently delayed by a few bugs. Couldn't we just > >> create a windows build from the stable branch? Are there modifications > >> to be done or is it as simple as just build the branch instead of the > >> trunk? > >> > > I can try during weekend. What is the stable branch - the tar ball ekiga > > 3.2 ? My patches to build ekiga master with device detection you find in > > http://mail.gnome.org/archives/ekiga-devel-list/2009-May/msg3.html > > http://sourceforge.net/tracker/?func=detail&aid=2785005&group_id=204472&atid=989748 > > Until upstream integrates this patch, couldn't this patch be applied > before building win version? This allows us to advance the win release... > Sorry for the late reply. Before answering I wanted to learn a bit about what naggs me. No, I do not think that releasing a Win32 Ekiga 3.2 is advisable before the so called "crash on exit" (COE) has been localized. First I would like to know whether COE is just a bug or two or something more general. Win32 is particularly affected. I cannot reproduce it under Linux though the valgrind output looks terrifying. I poked around a bit in contact-core replacing the current make_slot mechanism of chaining signals with the 3.02 one using sigc::mem_fun but with the new pointers to refcounted objects. I got rid of the emediate crash to find heap corruption: Breakpoint 1 at 0x435dd0: file ../../../lib/engine/account/account-core.cpp, line 48. (gdb) b Ekiga::ChatCore::~ChatCore() Breakpoint 2 at 0x476325: file ../../../lib/engine/chat/chat-core.cpp, line 40. (gdb) b Ekiga::ContactCore::~ContactCore() Breakpoint 3 at 0x477e64: file ../../../lib/engine/addressbook/contact-core.cpp, line 49. (gdb) c Continuing. [Switching to thread 1080.0x4ec] Breakpoint 2, Ekiga::ChatCore::~ChatCore (this=0x8178398) at ../../../lib/engine/chat/chat-core.cpp:40 in ../../../lib/engine/chat/chat-core.cpp (gdb) 40../../../lib/engine/chat/chat-core.cpp: No such file or directory. c Continuing. Breakpoint 3, Ekiga::ContactCore::~ContactCore (this=0x814bf40) at ../../../lib/engine/addressbook/contact-core.cpp:49 in ../../../lib/engine/addressbook/contact-core.cpp (gdb) 49../../../lib/engine/addressbook/contact-core.cpp: No such file or directory. c Continuing. Breakpoint 1, Ekiga::AccountCore::~AccountCore (this=0x814bec0) at ../../../lib/engine/account/account-core.cpp:48 in ../../../lib/engine/account/account-core.cpp (gdb) warning: Heap corruption detected at 08195C90 warning: Heap corruption detected at 08195DA0 warning: Heap corruption detected at 081DDF30 Then Ekiga gets lost looping between WinXP system dlls. Without gdb that may last for several minutes before it crashes and Visual Studio jumps in. I think that Win32 Ekiga suffers from heap corruption which with the current code leads to an emmediate crash. After reading http://bugzilla.gnome.org/show_bug.cgi?id=570008 where you, Eugene reported COE back in January I went back to SVN version 7603 which was supposed to be still ok. For Win32 it is not. It does not emmediately crash but has the heap corruption. Ekiga has lost Win32 earlier. I read about Snark's heroic attempt to directly fix COE last November in http://mail.gnome.org/archives/ekiga-devel-list/2008-November/msg00044.html . I think I do not have to repeat that. Instead I am just working on a little single theaded app which models Ekiga with its service-core, secondary cores and services, the latter two using sigc++ signals to communicate. Except of exercising in C++ I would like to compare Ekiga's gmref_ptr, libboost's shared_ptr and a combination of shared_ptr and weak_ptr. I aggree, thinking about the consequences of storing pointers to refcounted objects in signals sounds rather theoretical. Regarding the valgrind logs which I have read so far, I think, I will come to the point where the Win32 heap mechanisms which we use with Mingw32 will give in. Back to the original question. You can make calls with Win32 Ekiga. But with a not obvious bug (like code page characters in UTF-8) you will have to live with the danger of heap corruption which may also appear during normal program usage when objects are freed. I vote for fixing the "crash on exit" feature first. There is no Windows stable branch at the moment. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] windows stable branch
Am Mittwoch, den 13.05.2009, 18:25 +0200 schrieb Michael Rickmann: > Am Freitag, den 08.05.2009, 17:40 +0200 schrieb Eugen Dedu: > > Michael Rickmann wrote: > > > Am Freitag, den 08.05.2009, 13:41 +0200 schrieb Eugen Dedu: > > >> Hi, snip Sorry for the long line in the last post. I was copy pasting after Evolution and our MS Exchange server had sorted out their disagreements. Here three snippets of code and their valgrind logs regarding pointers in sigc++ signals. Two of the snippets were taken from http://mail.gnome.org/archives/libsigc-list/2006-August/msg5.html Regards Michael testcase.tar.gz Description: application/compressed-tar ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Crash on exit : dead?
Am Donnerstag, den 14.05.2009, 14:35 +0200 schrieb Julien Puydt: > Hi, > > I had once again checked the memory management in both the contact and > presence stacks, without finding any problem. > > I read the valgrind errors again and decided they meant a problem with > sigc::trackable : I changed to manual tracking, and got a big > improvement of the valgrind log. > > Does that fix the crash on exit? > > Snark For Win32 it is quite an improvement, thank you. In gdb I can reach now the last line of gui/main.cpp without detecting any heap corruption. This was not possible before. However, then Ekiga vanishes in ntdll.dll and does not exit. That may be Win32 specific and may be an issue of handling left over threads. Attached is the gdb log starting from the last line (I have a few additional ones to make std output unbuffered). I did a "thread apply all bt", continued and had to kill the program. It seems that these threads are still waiting for their mutexes. I will find out what they are. Regards Michael (gdb) (gdb) Breakpoint 1 at 0x40f88c: file gui/main.cpp, line 4634. (gdb) Continuing. [New thread 2704.0x100] [Switching to thread 2704.0x630] Breakpoint 1, winm...@16 (hInstance=0x350037, hPrevInstance=0x340037, lpCmdLine=0x7ffd7000 "", nCmdShow=-2141935304) at gui/main.cpp:4634 4634gui/main.cpp: No such file or directory. in gui/main.cpp (gdb) 4635 in gui/main.cpp (gdb) 0x7c816fd7 in RegisterWaitForInputIdle () from C:\WINDOWS\system32\kernel32.dll (gdb) Thread 21 (thread 2704.0x100): #0 0x7c91eb94 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll #1 0x7c91e31b in ntdll!ZwRemoveIoCompletion () from C:\WINDOWS\system32\ntdll.dll #2 0x7c80a746 in KERNEL32!GetQueuedCompletionStatus () from C:\WINDOWS\system32\kernel32.dll #3 0x77e570c8 in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #4 0x77e5720c in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #5 0x77e57294 in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #6 0x77e56a3d in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #7 0x77e56c03 in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #8 0x7c80b683 in KERNEL32!GetModuleFileNameA () from C:\WINDOWS\system32\kernel32.dll #9 0x in ?? () Thread 19 (thread 2704.0x618): #0 0x7c91eb94 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll #1 0x7c91e31b in ntdll!ZwRemoveIoCompletion () from C:\WINDOWS\system32\ntdll.dll #2 0x7c80a746 in KERNEL32!GetQueuedCompletionStatus () from C:\WINDOWS\system32\kernel32.dll #3 0x77e570c8 in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #4 0x77e5720c in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #5 0x77e57294 in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #6 0x77e56a3d in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #7 0x77e56c03 in RPCRT4!I_RpcBindingCopy () from C:\WINDOWS\system32\rpcrt4.dll #8 0x7c80b683 in KERNEL32!GetModuleFileNameA () from C:\WINDOWS\system32\kernel32.dll #9 0x in ?? () Thread 18 (thread 2704.0xa48): #0 0x7c91eb94 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll #1 0x7c91e9c0 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\system32\ntdll.dll #2 0x7c8025cb in WaitForSingleObjectEx () from C:\WINDOWS\system32\kernel32.dll #3 0x047c in ?? () #4 0x in ?? () Thread 17 (thread 2704.0xdd4): #0 0x7c91eb94 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll #1 0x7c91e9c0 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\system32\ntdll.dll #2 0x719b4033 in ?? () from C:\WINDOWS\system32\mswsock.dll #3 0x02d8 in ?? () #4 0x0001 in ?? () #5 0x0a1bf7f4 in ?? () #6 0x0103 in ?? () #7 0x in ?? () Thread 16 (thread 2704.0x850): #0 0x7c91eb94 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll #1 0x7c91e9c0 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\system32\ntdll.dll #2 0x719b4033 in ?? () from C:\WINDOWS\system32\mswsock.dll #3 0x02ec in ?? () #4 0x0001 in ?? () #5 0x09fbfa88 in ?? () #6 0x09fbfb40 in ?? () #7 0x081a0e70 in ?? () #8 0x09fbfb30 in ?? () #9 0x23f8a5b0 in ?? () #10 0x01c9d4ca in ?? () #11 0x in ?? () #12 0x7fff in ?? () #13 0x00283628 in ?? () #14 0x in ?? () Thread 15 (thread 2704.0xa20): #0 0x7c91eb94 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll #1 0x7c91e9ab in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\system32\ntdll.dll #2 0x7c8094e2 in KERNEL32!CreateFileMappingA () from C:\WINDOWS\system32\kernel32.dll #3 0x6cbe15f5 in ksproxy!KsGetMediaTypeCount () from C:\WINDOWS\system32\ksproxy.ax #4 0x7c80b683 in KERNEL32!GetModuleFileNameA () from C:\WINDOWS\system32\kernel32.dll #5 0x in ?? () Thread 14 (thread 2704.0xe50): #0 0x7c91eb94 in ntd
Re: [Ekiga-devel-list] windows stable branch
Am Freitag, den 15.05.2009, 21:10 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Freitag, den 08.05.2009, 17:40 +0200 schrieb Eugen Dedu: > >> Michael Rickmann wrote: > >>> Am Freitag, den 08.05.2009, 13:41 +0200 schrieb Eugen Dedu: > >>>> Hi, > >>>> > >>>> Windows build is currently delayed by a few bugs. Couldn't we just > >>>> create a windows build from the stable branch? Are there modifications > >>>> to be done or is it as simple as just build the branch instead of the > >>>> trunk? > >>>> > >>> I can try during weekend. What is the stable branch - the tar ball ekiga > >>> 3.2 ? My patches to build ekiga master with device detection you find in > >>> http://mail.gnome.org/archives/ekiga-devel-list/2009-May/msg3.html > > Should the above patch be applied right now? Or do you wait for another > solution? Yes, please apply it. I have used it all the time and it works. I attach another patch which is actually a work around. Without it Win32 Ekiga will not terminate waiting for something (thread completion?). > > >>> http://sourceforge.net/tracker/?func=detail&aid=2785005&group_id=204472&atid=989748 > Something odd has happened to that one. We are supposed to submit a patch for cross compilation. I have it at the level of configure.ac but my autoconf seems rather different from what the opal guys use. So I do not dare to go ahead. By the way there is another one affecting Win32: http://sourceforge.net/tracker/?func=detail&aid=2791741&group_id=204472&atid=989748 I think it is due to work in progress and we just have to be patient. With Snark's crash on exit fix and thee patches mentioned in this mail win32 Ekiga has about reached the state of version 3.0.2 as in the snapshots archive. Though, there may be another "hidden" crash which occurs during startup and only when using gdb. I have not cared for that one yet. It does not seem that urgent, and I do not feel really comfortable with Win32 gdb. Actually, I have sort of stress tested Win32 Ekiga for the last three days and had only a single crash. I think going for a 3.2.1 Win32 release is possible now. I will give the gnome 2.26 branch a try. Regards Michael diff -ur ekiga.orig/src/gui/main.cpp ekiga/src/gui/main.cpp --- ekiga.orig/src/gui/main.cpp 2009-05-17 14:04:50.590528002 +0200 +++ ekiga/src/gui/main.cpp 2009-05-17 14:16:47.841836268 +0200 @@ -4628,7 +4628,8 @@ iresult = main (argc, argv, env); } CloseHandle (ekr_mutex); - return iresult; + /* FIXME should be return iresult; (?) which currently does not terminate */ + exit (iresult); } #endif ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] windows stable branch
Am Dienstag, den 19.05.2009, 18:38 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Freitag, den 15.05.2009, 21:10 +0200 schrieb Eugen Dedu: > >> Michael Rickmann wrote: > >>> Am Freitag, den 08.05.2009, 17:40 +0200 schrieb Eugen Dedu: > >>>> Michael Rickmann wrote: > >>>>> Am Freitag, den 08.05.2009, 13:41 +0200 schrieb Eugen Dedu: > >>>>>> Hi, > >>>>>> > >>>>>> Windows build is currently delayed by a few bugs. Couldn't we just > >>>>>> create a windows build from the stable branch? Are there > >>>>>> modifications > >>>>>> to be done or is it as simple as just build the branch instead of the > >>>>>> trunk? > > another patch which is actually a work around. Without it Win32 Ekiga > > will not terminate waiting for something (thread completion?). > > Maybe make a ctrl-c when the program is supposed to be finished, and see > what all the threads are doing? > > >>>>> http://sourceforge.net/tracker/?func=detail&aid=2785005&group_id=204472&atid=989748 > > Something odd has happened to that one. We are supposed to submit a > > patch for cross compilation. I have it at the level of configure.ac but > > my autoconf seems rather different from what the opal guys use. So I do > > not dare to go ahead. By the way there is another one affecting Win32: > > ... > I opened a new report for that one specifying Win32 Ekiga's needs more concisely and provided a configure.ac patch, see http://sourceforge.net/tracker/?func=detail&aid=2794019&group_id=204472&atid=989748 > > http://sourceforge.net/tracker/?func=detail&aid=2791741&group_id=204472&atid=989748 > > I think it is due to work in progress and we just have to be patient. > > Seems this one is fixed too, is that right? Mostly, but there are some problems in the autoconf. I could comment on that and provide some diff some hours ago as the bug was not yet closed. > > > I think going for a 3.2.1 Win32 release is possible now. I will give the > > gnome 2.26 branch a try. > > Or 3.2.1 :o) > Why not! Everything is going so fast at the moment. So I tried to catch up. You can find a Win32 build from git branch gnome-2-26 this afternoon at http://wwwuser.gwdg.de/~mrickma/ekiga/ they are the *3.2.1_1 files. I needed two patches for opal corresponding to the two open wishes above and two for Ekiga (all contained in ekiga_build-3.2.1_1.tgz ). ekiga_exit.diff lets Ekiga shutdown semi-gracefully. ekiga_ldflags.diff seems to be needed by my cross compiler (Debian based install), to get the entry point right. Michael Cronenworth on Fedora got that right with the -mwindows flag from the Win32 Makefile. ! What interest me most with the files from http://wwwuser.gwdg.de/~mrickma/ekiga/ is 1) Do they work for anybody else than me? Does anybody on this list have a Windows computer, perhaps for the kids? Is the crash on exit really gone? Is the Stun/Registring problem gone for most of you? I still have a stun problem which is private I think. At home I am behind a Fritz!Box which is a NAT router and at the same time a SIP client. After a while of inactivity Ekiga first reports a "port restricted NAT" and I can not hear 5...@ekiga.net. When I shut it down and start again it reports "cone NAT" in the d4s and everything is fine (same on Linux). 2) Is my interpretation of the git commands to get the gnome-2-26 branch at http://wiki.ekiga.org/index.php/Download_Ekiga_sources right? I had to use a "git checkout -b gnome-2-26 origin/gnome-2-26" instead of "git checkout origin/gnome-2-26". Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] windows stable branch
Am Donnerstag, den 21.05.2009, 13:11 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Dienstag, den 19.05.2009, 18:38 +0200 schrieb Eugen Dedu: > >> Michael Rickmann wrote: > >>> Am Freitag, den 15.05.2009, 21:10 +0200 schrieb Eugen Dedu: > >>>> Michael Rickmann wrote: > >>>>> Am Freitag, den 08.05.2009, 17:40 +0200 schrieb Eugen Dedu: > >>>>>> Michael Rickmann wrote: > >>>>>>> Am Freitag, den 08.05.2009, 13:41 +0200 schrieb Eugen Dedu: > >>>>>>>> Hi, > >>>>>>>> > > I opened a new report for that one specifying Win32 Ekiga's needs more > > concisely and provided a configure.ac patch, see > > http://sourceforge.net/tracker/?func=detail&aid=2794019&group_id=204472&atid=989748 > > Just to be sure: this patch is general for opal win compilation, or is > it ekiga-specific? If the latter, it cannot be integrated in opal I > suppose... > It is Mingw32/CygWin specific. I understand that Opal/Ptlib is concentrating on the MS build system. As I understood they will include user provided patches for other build systems. > >>> snip Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Window Stable Testing
Am Dienstag, den 19.05.2009, 18:50 -0700 schrieb Bilbo: > Hi, > > I didn't want to risk top posting on the previous thread so created another. > > I ran a few tests today on the Windows version of Ekiga at the following > link http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.1_1-release.exe. > > I am running Ekiga on Windows Vista SP1, and registering with my Kamailio > 1.5 server. I was impressed with the version and appears very stable. The > application no longer crashes on exit :). > > One probelm I noticed with the release was the Ekiga process continues to > run after selecting, chat - quit from the ekiga menu. I'm not able to > register again until I kill the ekiga process in the task manager. This > problem didn't occur with Ekiga version 3.0.1. > Thank you for testing! Well that seems to be a serious problem. In principle that happens under XP as well. I applied a hack, letting the C library clean up a bit, which works under XP but apparently no longer under Vista. I just try to unwind Ekiga's threads on exit. Of a maximum of 15 threads there are 11 still active when I try to exit. One of them is orphaned in that the parent has allready been closed and it seems to own a device. I will get there, stay tuned for another try. > I'd be happy to test if the STUN issue is fixed. What is the bug # or would > you mind explaining the problem? > > Thanks I think that Ekiga's stun works rather well. Also Ekiga registers with ekiga.net without a problem. My problems start when making a call for the first time. Perhaps Ekiga still thinks it has to deal with a port restricted NAT as tested with the sever, whereas the router has decided to become a cone NAT. I have a situation comparable to two SIP clients behind a NAT router, only that the router is one of these clients itself. Under normal conditions, I think, nobody has to worry about Ekiga's STUN and NAT capabilities at the moment. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Mingw32 : Having problem with ffmpeg
I had trouble with ffmpeg as well. I realized that when doing an update- sources every now and then a new file was downloaded from SVN though I was requesting a specific SVN version. I think the ffmpeg guys have a problem keeping their SVN and git repositories in synchrony. On the git side they have a ffmpeg and a libswscale one. So I switched to ffmpeg git and tried to guess which ffmpeg version corresponds to which libswscale one, ffmpeg : d962d69f2ef1bcd3b4 and libswcale : 8c5952c02bfad4bfa6 is a good and rather recent pair. For reference how to download, configure and build, I attach my current Makefile. Regards Michael Am Freitag, den 05.06.2009, 12:47 -0400 schrieb e schmidbauer: > I am getting the exact same error using ekiga svn on ubuntu jaunty. i > have not found a solution either. > > On Fri, Jun 5, 2009 at 8:14 AM, paul hillereau > wrote: > > Hello, > > > > I am currently trying to cross-compile ekiga from git stable branch (gnome > > 2-26), and it failed due to some errors with ffmpeg library. I did make > > update-sources, and then make; i had to change the version for libxml2, > > since version 2.6.26 is no more available from ftp, so i use 2.6.30. > > Now i have this problem: > > > > ek...@winnie:/home/devel/win32/ekiga/win32: make snip Makefile_162.gz Description: GNU Zip compressed data ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Mingw32 : Having problem with ffmpeg
Am Montag, den 08.06.2009, 15:37 +0200 schrieb paul hillereau: > 2009/6/8 Michael Rickmann > I had trouble with ffmpeg as well. I realized that when doing > an update- > sources every now and then a new file was downloaded from SVN > though I > was requesting a specific SVN version. I think the ffmpeg guys > have a > problem keeping their SVN and git repositories in synchrony. > On the git > side they have a ffmpeg and a libswscale one. So I switched to > ffmpeg > git and tried to guess which ffmpeg version corresponds to > which > libswscale one, ffmpeg : d962d69f2ef1bcd3b4 and libswcale : > 8c5952c02bfad4bfa6 is a good and rather recent pair. For > reference how > to download, configure and build, I attach my current > Makefile. > Regards > Michael > > I do not have issue with ffmpeg so far, because i have an error when > cross-compiling PTLIB. I tried to change the version for PTLIB in your > Makefile but it does not solve my problem. I tried cross-compiling > from PTLIB 2.4.1, 2.6.1 and trunk i have got errors in vfw.cxx : > > Version 2.4.1: > > PTLIB_URL:= > https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/branches/v2_4 > > make[3]: Entering directory `/home/devel/win32/ekiga/win32/ptlib/src' > i586-mingw32msvc-g++ -gstabs -I/home/devel/win32/ekiga/win32/include > -march=pentium-mmx -DPTRACING -DP_FORCE_STATIC_PLUGIN -mms-bitfields > -DPTRACING=1 -I/home/devel/win32/ekiga/win32/ekiga/win32/directx > -fno-exceptions -Wall -g3 -ggdb -O0 -D_DEBUG > -I/home/devel/win32/ekig snip ... snip > a/win32/ptlib/include -c ptlib/common/vfakeio.cxx > [/home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/obj_d/vfw.o] Error > 1 > make[3]: Leaving directory `/home/devel/win32/ekiga/win32/ptlib/src' > make[2]: *** [debug] Error 2 > make[2]: Leaving directory `/home/devel/win32/ekiga/win32/ptlib/src' > make[1]: *** [debug] Error 2 > make[1]: Leaving directory `/home/devel/win32/ekiga/win32/ptlib' > make: *** [/home/devel/win32/ekiga/win32/lib/libpt_d_s.a] Error 2 > > I search for the vfw.h header file but i did not found it. I'm running > out of idea to get a clean cross-compile, any hints ? > I have looked through your logs. It appears that you have vfw.h but in a version too outdated for ptlib. If you work on a debian based system you may try to install http://wwwuser.gwdg.de/~mrickma/ekiga/mingwrt/mingw32-runtime_3.15-1_all.deb . I know Fedora has it as well but cannot find it at the moment. Otherwise you may consider to go to mingw.org, get the latest Win32 headers and poke them into your system. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Mingw32 : Having problem with ffmpeg
Am Dienstag, den 09.06.2009, 13:22 +0200 schrieb paul hillereau: > > I have looked through your logs. It appears that you have > vfw.h snip ..snip > > First I am very thankfull for all of your answers, thanks you for > spending some time on my problem. > > I installed the new mingw32 runtime on my debian lenny, and at least > issues with vfw vere solved. > But after changing the WINVER macro in > ptlib/include/ptlib/msos/ptlib/contain.h from value 0x500 (windows 2k) > to 0x501 (windows XP), which correct errors with getaddrinfo in > ekiga/win32/ptlib/src/ptlib/common/sockets.cxx; now there is a linker > error : > > [snip] > /home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/obj_d/contain.o > /home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/obj_d/object.o -lwinmm > -lwsock32 -lsnmpapi -lmpr -lcomdlg32 -lgdi32 -lavicap32 -liphlpapi -lole32 > -lregex -lexpat -ldsound -ldxerr9 -ldxguid -lstrmiids -lole32 -luuid > -loleaut32 -lquartz -ldnsapi > > /home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/obj_d/sockets.o: In > function `_ZN11PHostByName7GetHostERK7PString': > /home/devel/win32/ekiga/win32/ptlib/src/ptlib/common/sockets.cxx:532: > undefined reference to `_getaddri...@16' > /home/devel/win32/ekiga/win32/ptlib/src/ptlib/common/sockets.cxx:535: > undefined reference to `_freeaddri...@4' > collect2: ld returned 1 exit status > make[3]: *** > [/home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/libpt_d.dll.2.7-beta0] > Error 1 > make[3]: Leaving directory `/home/devel/win32/ekiga/win32/ptlib/src' > make[2]: *** [debug] Error 2 > Seems I will have to submit another patch to their build system. In the meantime try to change into the directory from which the Makefile issued the link command and repeat it by hand appending "-lws2_32" without the quotes. You will have to do that also when linking Ekiga. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Mingw32 : Having problem with ffmpeg
Am Mittwoch, den 10.06.2009, 11:29 +0200 schrieb Hillereau Paul:
> Now ptlib had been compiled, I have difficulties with opal. I have 2
> errors when h264 and h263, I might disable those codecs, but it might be
> difficult to compile ekiga after ?
> I can disable h264 by adding --disable-h264 to confopal in the main
> Makefile, but I did not find a similar option to disable h263.
> Here is my error (it's above the same for h263) :
>
> make[3]: Entering directory
> `/home/devel/win32/ekiga/win32/opal/plugins/video/H.264'
> i586-mingw32msvc-g++ -gstabs -I../../../include
> -I/home/devel/win32/ekiga/win32/include -I../common -I../../
> -DLIB_DIR='"/home/devel/win32/ekiga/win32/lib"'
> -DVC_PLUGIN_DIR='"opal-3.7.0/codecs/video"' -DLICENCE_MPL -g3 -ggdb
> -O0 -D_DEBUG -I/home/devel/win32/ekiga/win32/include -march=pentium-mmx
> -DPTRACING -c h264-x264.cxx -o obj/h264-x264.o
> In file included from ../common/ffmpeg.h:67,
> from ../common/dyna.h:44,
> from h264-x264.cxx:53:
> ../common/vs-stdint.h:33:2: error: #error "Use this header only with
> Microsoft Visual C++ compilers!"
snip
You are not alone with that. They have changed things again. I tried
last night and had exactly the same build errors. Find attached the
patch for ptlib and the two for opal. Place them into the diff directory
and make the copy sections of the Makefile look as in attached addtomake
file.
Regards
Michael
diff -ur src/ptlib/configure ptlib/configure
--- src/ptlib/configure 2009-06-09 17:47:00.637030459 +0200
+++ ptlib/configure 2009-06-09 20:01:25.481030439 +0200
@@ -4520,7 +4520,7 @@
TARGETDIR=msos ;
SHAREDLIBEXT="dll" ;
STDCCFLAGS="$STDCCFLAGS -mms-bitfields" ;
- ENDLDLIBS="-lwinmm -lwsock32 -lsnmpapi -lmpr -lcomdlg32 -lgdi32 -lavicap32 -liphlpapi -lole32" ;
+ ENDLDLIBS="-lwinmm -lwsock32 -lws2_32 -lsnmpapi -lmpr -lcomdlg32 -lgdi32 -lavicap32 -liphlpapi -lole32" ;
NEEDS_PTHREADS=no ;
{ echo "$as_me:$LINENO: checking for swab" >&5
echo $ECHO_N "checking for swab... $ECHO_C" >&6; }
diff -ur src/ptlib/configure.ac ptlib/configure.ac
--- src/ptlib/configure.ac 2009-06-09 17:47:00.653032217 +0200
+++ ptlib/configure.ac 2009-06-09 19:59:54.409031582 +0200
@@ -302,7 +302,7 @@
TARGETDIR=msos ;
SHAREDLIBEXT="dll" ;
STDCCFLAGS="$STDCCFLAGS -mms-bitfields" ;
- ENDLDLIBS="-lwinmm -lwsock32 -lsnmpapi -lmpr -lcomdlg32 -lgdi32 -lavicap32 -liphlpapi -lole32" ;
+ ENDLDLIBS="-lwinmm -lwsock32 -lws2_32 -lsnmpapi -lmpr -lcomdlg32 -lgdi32 -lavicap32 -liphlpapi -lole32" ;
NEEDS_PTHREADS=no ;
AC_CHECK_FUNC([swab], [AC_DEFINE([USE_SYSTEM_SWAB], [], [Use system swab()] )] )
HAS_SHM_VIDEO=
diff -ur src/ptlib/src/ptlib/common/sockets.cxx ptlib/src/ptlib/common/sockets.cxx
--- src/ptlib/src/ptlib/common/sockets.cxx 2009-05-27 17:13:56.320289152 +0200
+++ ptlib/src/ptlib/common/sockets.cxx 2009-06-09 19:59:54.413033488 +0200
@@ -31,6 +31,11 @@
* $Date: 2009-05-25 05:26:23 +0200 (Mo, 25. Mai 2009) $
*/
+#if defined(__MINGW32__) && (!defined(WINVER) || (WINVER == 0x500))
+#undef WINVER
+#define WINVER 0x501
+#endif // __MINGW32__
+
#include
#include
@@ -60,8 +65,10 @@
DWORD cbTransferred,
LPWSAOVERLAPPED lpOverlapped,
DWORD dwFlags);
-
+#if defined(__MINGW32__) && (WINVER < 0x500)
+#undef AI_NUMERICHOST
+#endif // __MINGW32__
#endif // _WIN32_WCE
#endif // _WIN32
#endif // P_QOS
diff -ur src/opal/plugins/video/common/ffmpeg.h opal/plugins/video/common/ffmpeg.h
--- src/opal/plugins/video/common/ffmpeg.h 2009-06-09 17:47:35.337032739 +0200
+++ opal/plugins/video/common/ffmpeg.h 2009-06-09 22:07:03.941034240 +0200
@@ -63,7 +63,7 @@
extern "C" {
-#ifdef _WIN32
+#if defined (_WIN32) && defined (_MSC_VER)
#include "vs-stdint.h"
#define LIBAVCODEC_HEADER "libavcodec\avcodec.h"
#pragma warning(push)
diff -ur opal.pre/plugins/video/H.263-1998/h263-1998.cxx opal/plugins/video/H.263-1998/h263-1998.cxx
--- opal.pre/plugins/video/H.263-1998/h263-1998.cxx 2009-06-09 22:08:50.361264887 +0200
+++ opal/plugins/video/H.263-1998/h263-1998.cxx 2009-06-09 22:26:29.357035570 +0200
@@ -46,6 +46,10 @@
*/
+#ifndef PLUGIN_CODEC_DLL_EXPORTS
+#include "plugin-config.h"
+#endif
+
#define _CRT_SECURE_NO_DEPRECATE
#include "h263-1998.h"
diff -ur opal.pre/plugins/video/H.263-1998/Makefile.in opal/plugins/video/H.263-1998/Makefile.in
--- opal.pre/plugins/video/H.263-1998/Makefile.in 2009-06-09 22:08:50.361264887 +0200
+++ opal/plugins/video/H.263-1998/Makefile.in 2009-06-09 22:24:50.941032598 +0200
@@ -33,6 +33,7 @@
COMMONDIR =../common
PLUGINDIR =../../
OBJDIR =./obj
+PLUGINDIR =../..
CC =...@cc@
CFLAGS =...@cflags@
@@ -42,6 +43,7 @@
STDCCFLAGS =...@stdccflags@
libavcodec_cfla...@libavcodec_cflags@
LDFLAGS =...@ldflags@ -lavcodec -lavutil
+EXTRACFLAGS =-I$(PLUGINDIR)
have_li
[Ekiga-devel-list] Win32 please test
Hello everybody, I have a new Windows version of Ekiga head based on attached minimal but rather effective patches. you find it in my directory at http://wwwuser.gwdg.de/~mrickma/ekiga/ . As to the patches: 1) ekiga_linkmagic.diff : It allows the linker to chose WinMain as the entry point. Result is that the C-library is initialized properly and Ekiga exits gracefully, at least on XP. Additionally Ekiga can be compiled with the -mwindows flag as Michael Cronenworth suggested. 2) The option to start Ekiga on login which was given in the installer resulted in a non responsive icon in the Windows system tray. You could just quit or ask for help. Ekiga has its own option to start minimized which works very well under Windows. Please test whether the new attempt works for you. I would like to know whether Ekiga really shuts down on Vista or whether it has to be killed with the task manager. Regards Michael diff -ur src/ekiga/src/gui/main.cpp ekiga/src/gui/main.cpp --- src/ekiga/src/gui/main.cpp 2009-06-10 17:46:41.362449431 +0200 +++ ekiga/src/gui/main.cpp 2009-06-10 17:48:20.142449909 +0200 @@ -4329,6 +4329,10 @@ return gtk_image_get_pixbuf (GTK_IMAGE (mw->priv->main_video_image)); } +#ifdef WIN32 +// linker magic +#define main(c,v,e) ekigas_real_main(c,v,e) +#endif /* The main () */ int diff -ur src/ekiga/win32/nsisinstaller/ekiga.nsi ekiga/win32/nsisinstaller/ekiga.nsi --- src/ekiga/win32/nsisinstaller/ekiga.nsi 2009-04-19 18:08:42.860313875 +0200 +++ ekiga/win32/nsisinstaller/ekiga.nsi 2009-06-11 13:58:35.729786000 +0200 @@ -393,7 +393,7 @@ Section $(EKIGA_RUN_AT_STARTUP) SecStartup SetOutPath $INSTDIR - CreateShortCut "$SMSTARTUP\Ekiga.lnk" "$INSTDIR\ekiga.exe" "" "" 0 SW_SHOWMINIMIZED + CreateShortCut "$SMSTARTUP\Ekiga.lnk" "$INSTDIR\ekiga.exe" "" "" 0 SW_SHOWNORMAL SectionEnd SubSectionEnd ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 please test
paul hillereau schrieb: Michael Rickmann a écrit : Hello everybody, snip Thanks you, I will test it tomorrow when back at school. May I ask if you experiment any issue when linking ekiga, and how did you manage to workaround it (if you had any). Since yesterday I have got a segmentation fault when trying to link ekiga, and I do not understand from where it comes. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list I had worked a bit on Win32 Ekiga some time ago when it was still using SDL video output. From that time I knew by reading libsdl's source code that they were using a similar redefinition of main. Additionally I looked at the source code of Mingw runtime and there it says /* * Call the main function. If the user does not supply one * the one in the 'libmingw32.a' library will be linked in, and * that one calls WinMain. See main.c in the 'lib' dir * for more details. */ So I let the preprocessor give main some other name and WinMain is called after the C-library has been initialized and returns there for finalizing things. As to your segfault while linking - sorry, but I have no idea. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Could not unregister, regression
This is Ekigas answer in the accounts window on Linux now. With the current git version I cannot unregister my account at ekiga.net any longer. Also the subcriber threads do not terminate any longer. Ekiga needs considerably longer to shutdown than it took one week ago and does not shut down at all when run under gdb. This is EKIGA_3_2_0-214-g0941186 and ptlib/opal version 22850. I attach the out put from an gdb --args ekiga -d 1 where I set three brakepoints, b main.cpp:4562 b sip-endpoint.cpp:554 b sip-endpoint.cpp:610 All I was doing was registering in the accounts window and unregistering again, then quit. Clearly the subscriber thread 1755 manages to register as the callback OnRegistered is called, but it makes no use of AutoDeleteThread and is still active at program end. The subscriber 1756 used to unsubscribe behaves similarly but does not manage to trigger an OnRegistered callback. Another change is that a week ago I could outcomment the unsubscribe function in sip-endpoint.cpp:552 and the linker would not complain. Now it is needed. Another point: Ekiga cannot be compiled since opal version 2258 because the SIPEndPoint::Message form called in sip-endpoint.cpp:360 no longer exists. Regards Michael Could not unregister Starting program: /home/mrickma/src/ekiga-head/linux/ekiga/src/ekiga -d 1 [Thread debugging using libthread_db enabled] [New Thread 0xb58a3730 (LWP 1230)] [Switching to Thread 0xb58a3730 (LWP 1230)] main (argc=3, argv=0xbfd36274) at gui/main.cpp:4347 4347 gchar *url = NULL; (gdb) c Continuing. 2009/06/14 19:50:02.757 0:08.216 Version 3.3.0 by on Unix Linux (2.6.28-11-generic-i686) with PTLib (v2.7beta0) at 2009/6/14 19:50:02.757 2009/06/14 19:50:02.757 0:08.216 Ekiga git revision: EKIGA_3_2_0-214-g0941186 [New Thread 0xb5417b90 (LWP 1492)] [New Thread 0xb53d6b90 (LWP 1493)] [New Thread 0xb5395b90 (LWP 1495)] 2009/06/14 19:50:02.772 0:08.231 Detecting V4L2 devices [New Thread 0xb5354b90 (LWP 1670)] 2009/06/14 19:50:03.253 0:08.712 OpalMan Registered endpoint with prefix pc 2009/06/14 19:50:03.384 0:08.843 OpalMan Registered endpoint with prefix sip [New Thread 0xb5313b90 (LWP 1680)] [New Thread 0xb52d2b90 (LWP 1682)] 2009/06/14 19:50:03.391 0:08.850 OpalMan Registered endpoint with prefix sips [New Thread 0xb5291b90 (LWP 1684)] 2009/06/14 19:50:03.405 0:08.864 OpalMan Registered endpoint with prefix h323 2009/06/14 19:50:03.405 0:08.864 OpalMan Registered endpoint with prefix h323s [New Thread 0xb5250b90 (LWP 1687)] [New Thread 0xb520fb90 (LWP 1696)] [New Thread 0xb51b4b90 (LWP 1700)] [New Thread 0xb49b3b90 (LWP 1703)] 2009/06/14 19:50:03.917 0:09.376 Detecting V4L2 devices 2009/06/14 19:50:04.395 0:09.854 PVidInDev Open() videoFd:-1 2009/06/14 19:50:04.395 0:09.854 PVidInDev Close() videoFd:-1 started:0 2009/06/14 19:50:04.395 0:09.854 Detecting V4L2 devices 2009/06/14 19:50:04.855 0:10.314 PVidInDev Open() devName:/dev/video0 videoFd:-1 2009/06/14 19:50:05.031 0:10.490 PVidInDev G_PARM failed : Invalid argument 2009/06/14 19:50:05.031 0:10.490 VideoInputDeviceS_STD failed : Invalid argument 2009/06/14 19:50:05.032 0:10.491 PVidInDev G_PARM failed (preserving frame rate may not work) : Invalid argument 2009/06/14 19:50:05.032 0:10.491 PVidInDev G_PARM failed (preserving frame rate may not work) : Invalid argument 2009/06/14 19:50:05.323 0:10.782 StunDetector:0xb520fb90 PTLib Destroyed thread 0x87dffc0 StunDetector:0xb520fb90(id = b520fb90) [Thread 0xb520fb90 (LWP 1696) exited] 2009/06/14 19:50:05.696 0:11.155 Ekiga version 3.3.0 2009/06/14 19:50:05.696 0:11.155 OPAL version 3.7.0 2009/06/14 19:50:05.696 0:11.155 PTLIB version 2.7.0 2009/06/14 19:50:05.696 0:11.155 GNOME support disabled 2009/06/14 19:50:05.696 0:11.155 Accelerated rendering support enabled 2009/06/14 19:50:05.696 0:11.155 DBUS support disabled 2009/06/14 19:50:05.696 0:11.155 GConf support enabled 2009/06/14 19:50:05.696 0:11.155 ESound support disabled [New Thread 0xb4371b90 (LWP 1750)] 2009/06/14 19:50:06.278 0:11.737 GMVideoOut...0xb5395b90 XVideo XQueryShmExtension success 2009/06/14 19:50:06.278 0:11.737 GMVideoOut...0
Re: [Ekiga-devel-list] Could not unregister, regression
Eugen Dedu schrieb: Michael Rickmann wrote: longer. Also the subcriber threads do not terminate any longer. Ekiga needs considerably longer to shutdown than it took one week ago and does I noticed it too... Another point: Ekiga cannot be compiled since opal version 2258 because the SIPEndPoint::Message form called in sip-endpoint.cpp:360 no longer exists. I am working on this. Strange things are accumulating at this point. I went back to Ekiga 7bb1d0 (Updated Spanish translation) and Opal/ptlib 22836 which correspond to the state at Wed Jun 10. Ekiga's unregistration was already broken at that time. But the subsriber threads were still shutting down and Ekiga could shut down under gdb. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Could not unregister, regression
...snip
> > Looking at a -d 4, it seems that ekiga asks to unregister by trying to
> > register again, and gets a 489 Bad event back...
> >
> > Perhaps my recent refactoring of the account code is responsible for the
> > problem...
>
> Uh... from lib/engine/components/opal/sip-endpoint.cpp :
> bool
> Opal::Sip::EndPoint::subscribe (const Opal::Account & account)
> {
>if (account.get_protocol_name () != "SIP")
> return false;
>
>new subscriber (account, *this);
>return true;
> }
>
>
> bool
> Opal::Sip::EndPoint::unsubscribe (const Opal::Account & account)
> {
>if (account.get_protocol_name () != "SIP")
> return false;
>
>new subscriber (account, *this);
>return true;
> }
>
> Is it me or is it doing the same thing in both cases !?
>
> Snark
I was wondering about that one as well. All I can say is that the
unsubscribe was not used. When studying Ekiga#s exit, I had outcommented
it by a diff the file date of which is Mo 8 Jun and the linker did not
complain. Now unsubscribe is called.
Regards
Michael
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Could not unregister, regression
Am Mittwoch, den 17.06.2009, 19:16 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > needs considerably longer to shutdown than it took one week ago and does > snip > So it took 6 seconds to wait for the last thread... > > Otherwise, it seems this is the last remaining issue among all those you > have risen, is that right? > Yes, it is the last one. Surprisingly it effects especially Linux Ekiga. After Sparks fix. The shutdown time under WinXP was reduced to about one sec - it was ~3 sec before. Under Win7RC Ekiga is shut down so fast that I cannot guess. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] alien registrar problem
I can not convince recent git revisions of ekiga to register with my phone provider (1und1.de). I get an "could not register (Forbidden, please check that username and password are correct)" answer, same error on Linux and Windows. I tested from behind a FritzBox as a NAT router: git-Linux no, git-WinXP no, git-Win7RC no, 3.02-WinXP yes. On a different computer with an official IP: git-Linux no. For attached d4 log I started up Ekiga which was registering to ekiga.net. Then I manually enabled my other account sip.1und1.de resulting in above error. Then I shut down again. This behaviour seems not related to the number of accounts but to, ekiga.net or not. Additionally, Ekiga crashes on Windows only, when I delete an account. There may be a connection between the two errors and the difference in crashing may be caused by the difference in gmconf storing. The registering problem may be related to what thomas schorp reported in http://mail.gnome.org/archives/ekiga-devel-list/2009-June/msg00036.html . At that time I was still happy with my Windows version connecting to ekiga.net. Does ekiga.net not require a password? Can I register with any string? That seems to be the case. Regards Michael 1und1-d4.log.gz Description: GNU Zip compressed data ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Am Dienstag, den 23.06.2009, 15:02 +0200 schrieb Damien Sandras: > Le mardi 23 juin 2009 à 14:39 +0200, Michael Rickmann a écrit : > > I can not convince recent git revisions of ekiga to register with my > > phone provider (1und1.de). I get an "could not register (Forbidden, > > please check that username and password are correct)" answer, same error > > on Linux and Windows. I tested from behind a FritzBox as a NAT router: > > git-Linux no, git-WinXP no, git-Win7RC no, 3.02-WinXP yes. On a > > different computer with an official IP: git-Linux no. For attached d4 > > log I started up Ekiga which was registering to ekiga.net. Then I > > manually enabled my other account sip.1und1.de resulting in above error. > > Then I shut down again. This behaviour seems not related to the number > > of accounts but to, ekiga.net or not. > > Additionally, Ekiga crashes on Windows only, when I delete an account. > > There may be a connection between the two errors and the difference in > > crashing may be caused by the difference in gmconf storing. > > The registering problem may be related to what thomas schorp reported in > > http://mail.gnome.org/archives/ekiga-devel-list/2009-June/msg00036.html . > > At that time I was still happy with my Windows version connecting to > > ekiga.net. Does ekiga.net not require a password? Can I register with > > any string? That seems to be the case. > > It tells: > SIP/2.0 403 Keine RFC1918-IPs erlaubt > > That seems to be the reason. Not sure why. You should try a capture with > only that account active, for clarity. > -- snip Yes that is the only German string in there saying no RFC1918-IPs allowed. I attach the 1und1only log. Admittedly network setup of my computer here is a bit complicated. It has two interfaces, one to the free internet and one to our lab network where also the nameservers are. Kernel-IP-Routentabelle ZielRouter Genmask Flags Metric RefUse Iface 192.168.21.0* 255.255.255.0 U 0 00 eth1 link-local * 255.255.0.0 U 1000 00 eth1 localnet* 255.255.0.0 U 0 00 eth0 default gr-physio1-145. 0.0.0.0 UG10000 eth0 I checked ekiga.net requires a password. However, Ekiga seems to pick up a password change only the next time it is started. I will report the d4 log from home this evening. Regards Michael 1und1only-d4.log.gz Description: GNU Zip compressed data ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Am Dienstag, den 23.06.2009, 16:11 +0200 schrieb Eugen Dedu: > Damien Sandras wrote: > > Le mardi 23 juin 2009 à 14:39 +0200, Michael Rickmann a écrit : > >> I can not convince recent git revisions of ekiga to register with my > >> phone provider (1und1.de). I get an "could not register (Forbidden, > >> please check that username and password are correct)" answer, same error snip > > > > It tells: > > SIP/2.0 403 Keine RFC1918-IPs erlaubt > > > > That seems to be the reason. Not sure why. You should try a capture with > > only that account active, for clarity. > > You could also compare or send us the -d 4 output on current git version > and on 2-weeks-old version, to see what has changed... > > -- > Eugen Well, after an upgrade to Jaunty this computer has been ill, avahi was talking nonsense of a .local net, gave up and Ekiga did not work at all. Reason for that was that I had an eth0 and eth0:1 on the same interface card. It started to work a few days ago when I put in an extra eth1. So I have no real recent comparison. And at home I never tried 1und1.de from Ekiga as we have it on our regular phones. I will try standard Jaunty ekiga first and then jump somewhere into git / SVN, perhaps before the overhaul of the account window. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Michael Rickmann schrieb: Am Dienstag, den 23.06.2009, 16:11 +0200 schrieb Eugen Dedu: Damien Sandras wrote: Le mardi 23 juin 2009 à 14:39 +0200, Michael Rickmann a écrit : I can not convince recent git revisions of ekiga to register with my phone provider (1und1.de). I get an "could not register (Forbidden, please check that username and password are correct)" answer, same error snip It tells: SIP/2.0 403 Keine RFC1918-IPs erlaubt That seems to be the reason. Not sure why. You should try a capture with only that account active, for clarity. You could also compare or send us the -d 4 output on current git version and on 2-weeks-old version, to see what has changed... -- Eugen Well, after an upgrade to Jaunty this computer has been ill, avahi was talking nonsense of a .local net, gave up and Ekiga did not work at all. Reason for that was that I had an eth0 and eth0:1 on the same interface card. It started to work a few days ago when I put in an extra eth1. So I have no real recent comparison. And at home I never tried 1und1.de from Ekiga as we have it on our regular phones. I will try standard Jaunty ekiga first and then jump somewhere into git / SVN, perhaps before the overhaul of the account window. Regards Michael Sorry, for the uproar. I found the answer myself. I should have googled before: http://bugzilla.gnome.org/show_bug.cgi?id=579832 A provider bug from Ekiga#s point of view? Also when I google for Keine erlaubt "RFC1918 IPs " its mainly 1und1 who show up here in Germany. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Damien Sandras schrieb: Le mardi 23 juin 2009 à 16:15 +0200, Michael Rickmann a écrit : Am Dienstag, den 23.06.2009, 15:02 +0200 schrieb Damien Sandras: Le mardi 23 juin 2009 à 14:39 +0200, Michael Rickmann a écrit : snip What happens is that your contact field has 2 IP addresses : - 1 public IP - 1 private IP (with lower priority) The remote SER is misconfigured and rejects the packets because one of the IPs is private while the public one is reachable. You should contact them. Btw, is that a recent trunk ? Something else seems to be broken (without affecting the failure you see or being related to it). It is 2009-06-22 18:45:38 83b71c1b57b0cb15Made the SIP endpoint cache the default address of record, at the moment 21 hrs old. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Am Dienstag, den 23.06.2009, 18:16 +0200 schrieb Damien Sandras: > Le mardi 23 juin 2009 à 18:09 +0200, Michael Rickmann a écrit : > > Damien Sandras schrieb: > > > Le mardi 23 juin 2009 à 16:15 +0200, Michael Rickmann a écrit : > > >> Am Dienstag, den 23.06.2009, 15:02 +0200 schrieb Damien Sandras: > > >>> Le mardi 23 juin 2009 à 14:39 +0200, Michael Rickmann a écrit : > > > > snip > > > > > > > > What happens is that your contact field has 2 IP addresses : > > > - 1 public IP > > > - 1 private IP (with lower priority) > > > > > > The remote SER is misconfigured and rejects the packets because one of > > > the IPs is private while the public one is reachable. You should contact > > > them. > > > > > > Btw, is that a recent trunk ? Something else seems to be broken (without > > > affecting the failure you see or being related to it). > > > > It is 2009-06-22 18:45:38 83b71c1b57b0cb15Made the SIP > > endpoint cache the default address of record, at the moment 21 hrs old. > > And for opal ? > -- I am back at the computer now on which I compiled. Its opal SVN 22948 (2009-06-22T03:02:20.998594Z) and ptlib SVN 22945 (2009-06-22T01:49:54.035585Z) with which I had linked Ekiga, so approx. two days old. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Cross-compiling ekiga for win32
Am Freitag, den 26.06.2009, 01:48 +0200 schrieb Julien Puydt:
> Michael Cronenworth a écrit :
> > It depends on what OS you are building on. The files in win32/ are meant
> > for Debian. For Fedora or Windows you would need to customize it a little.
>
> I'm using debian. I already had a few problems :
> - libxml' 2.6.26 isn't available anymore ;
> - the openldap compilation fails with :
> slapdmsg.rc -O coff -o slapdmsg.res
> make[1]: slapdmsg.rc : commande introuvable (means: command not found)
>
> the Makefile (openldap's libraries/liblutil/ Makefile to be precise)
> target triggering the problem is :
> lapdmsg.res: slapdmsg.rc slapdmsg.bin
> $< -O coff -o $@
>
> which doesn't look very honest.
>
> It's pretty late... uh... early, so I don't think I'll be able to get
> myself out of this problem before some rest :-/
>
> Snark
Over the weekend I have stripped down my build process and can make a
suggestion how to revise Ekiga's Win32 build - Debian based only, sorry,
but better than the current.
First, I would like to submit three patches which should go to Ekiga's
code directly.
1ekiga_linkmagic.diff allows the linker to choose the correct entry
point for a Win32 gui application, so that one can use the -mwindows
flag.
2ekiga_shownormal.diff fixes a bug in the installer which would render
Ekiga unusable after a default installation. To start Ekiga minimized
you have to use Ekiga's own option not the Windows' one.
3ekiga_mvredir.diff fixes a problem under Windows 7 (possibly Vista
too). Current Ekiga writes its log files into the application directory.
Win7 allows this, but the files are sometimes truncated or they just
vanish. It appears they use some mapping to protect the application
programs. I would suggest to write the log files onto the user's desktop
if debug output was requested.
Now to the Ekiga's win32 directory. The current diff subdirectory
containes useless diffs. It is needed, however, to hold permanent and
temporary patches. Currently there are three for opal and one for ptlib
- I will file bug reports for them. The ptlib one is especially nasty
because it is Mingw's Win32 headers which are wrong (the WINVER issue),
but they seem to prefer being on the conservative side.
Finally, in the Makefile I have upgraded the versions of the required
libs mostly. libsasl2 and celt were added. And I changed to downloading
from git where required (Ekiga) or more reliable (ffmpeg).
I attach two forms of the changes to the win32 subdir, a long patch and
as an archive of the changed / required files.
As we cannot download the win32 subdir separately from git. Starting to
build Ekiga would change as follows.
Obtain Ekiga
git clone git://git.gnome.org/ekiga
Make a copy of the win32 directory
cp -a ekiga/win32 .
Change into that subdirectory, it will be your "BUILDROOT"
cd win32
Get all the sources
make update-sources
Build Ekiga
make
The Makefile will try to move the already downloaded Ekiga to the right
place during the make update-sources.
I hope it helps.
Regards
Michael
diff -ur ekiga.orig/src/gui/main.cpp ekiga/src/gui/main.cpp
--- ekiga.orig/src/gui/main.cpp 2009-06-28 08:17:31.0 +0200
+++ ekiga/src/gui/main.cpp 2009-06-28 08:18:58.0 +0200
@@ -4307,6 +4307,10 @@
return gtk_image_get_pixbuf (GTK_IMAGE (mw->priv->main_video_image));
}
+#ifdef WIN32
+// the linker must not find main
+#define main(c,v,e) ekigas_real_main(c,v,e)
+#endif
/* The main () */
int
diff -ur src/ekiga/win32/nsisinstaller/ekiga.nsi ekiga/win32/nsisinstaller/ekiga.nsi
--- src/ekiga/win32/nsisinstaller/ekiga.nsi 2009-04-19 18:08:42.860313875 +0200
+++ ekiga/win32/nsisinstaller/ekiga.nsi 2009-06-11 13:58:35.729786000 +0200
@@ -393,7 +393,7 @@
Section $(EKIGA_RUN_AT_STARTUP) SecStartup
SetOutPath $INSTDIR
- CreateShortCut "$SMSTARTUP\Ekiga.lnk" "$INSTDIR\ekiga.exe" "" "" 0 SW_SHOWMINIMIZED
+ CreateShortCut "$SMSTARTUP\Ekiga.lnk" "$INSTDIR\ekiga.exe" "" "" 0 SW_SHOWNORMAL
SectionEnd
SubSectionEnd
diff -ur ekiga.orig/src/gui/main.cpp ekiga/src/gui/main.cpp
--- ekiga.orig/src/gui/main.cpp 2009-06-28 08:22:05.0 +0200
+++ ekiga/src/gui/main.cpp 2009-06-28 08:23:30.0 +0200
@@ -4410,6 +4410,13 @@
text_label = g_strdup_printf ("PTLIB_TRACE_CODECS_USER_PLANE=%d", debug_level_up);
_putenv (text_label);
g_free (text_label);
+ if (debug_level != 0) {
+string desk_path = g_get_user_special_dir (G_USER_DIRECTORY_DESKTOP);
+if (!desk_path.empty ()) {
+ std::freopen((desk_path + "\\ekiga-stdout.txt").c_str (), "w", stdout);
+ std::freopen((desk_path + "\\ekiga-stderr.txt").c_str (), "w", stderr);
+}
+ }
#endif
/* Ekiga initialisation */
@@ -4579,9 +4586,6 @@
/* use msvcrt.dll to parse command line */
__getmainargs (&argc, &argv, &env, 0, &info);
-std::freopen("stdout.txt", "w", stdout);
-std::freopen("stderr.txt", "w", stderr);
-
iresult = main (argc, argv, env);
}
CloseHandle (e
Re: [Ekiga-devel-list] Cross-compiling ekiga for win32
Am Montag, den 29.06.2009, 14:19 +0200 schrieb Julien Puydt: > Michael Rickmann a écrit : > > > > I pushed all your changes in. Thanks, I will test it as soon as possible. It should be ok, one never knows. > > There's something I don't get : why do you want to download ekiga if you > already have it on disk? make tries to move the download if it finds it at the most probable location: ifeq ($(wildcard $(SRCDIR)/$(EKIGA_ARCHIVE)),) ifneq ($(wildcard $(BUILDROOT)/../$(EKIGA_ARCHIVE)/.git),) update-ekiga: echo --- Moving Ekiga master... $(MV) $(BUILDROOT)/../$(EKIGA_ARCHIVE) $(SRCDIR) else I and the Makefile are just used to have all sources in one subdir. > Perhaps it's something you don't know about autotools : they allow > out-of-tree builds. You have your sources in $WHATEVER_DIR, but want to > build in $THIS_DIR : > $ mkdir -p $THIS_DIR > $ cd $THIS_DIR > $ $WHATEVER_DIR/configure $CONFFLAGS > $ make > > This will build the usual program ; if in another console you do : > $ ~/bin/setup_for_cross_compile > $ mkdir -p $(THIS_DIR)_cross > $ cd $(THIS_DIR)_cross > $ $WHATEVER_DIR/configure $CROSS_CONFFLAGS > $ make > > Then the same sources will be built with very different options in > different directories. > Now I remember, I used that when I was building the cross tools myself, gcc uses that scheme. > Hope this helps, > It may come in the next revision of the Makefile for a couple of sources. For those sources, which we are working on, copying the source and building in tree was what the Makefile was providing for up to now, but building from a separate git clone may be even easier. > Snark > ___ Thanks Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Christian Schäfer schrieb: Damien Sandras wrote: The problem is that your router replaces the public IP address Ekiga puts in by a private one due to a bug in the router itself, you can see the Ekiga PDUs in the log, they are correct. If you disable STUN, perhaps your router will put the public IP address in the packets. What happens is that some dummy routers replace public ip's by private ones. That's your case. Don't think that's true. As I said, using twinkle behind the NAT with the same router works perfectly with that provider. So the router couldn't be the problem here and it seems that it's indeed a software issue. Please show me a trace of Ekiga with stun disabled and a trace of twinkle so that we can compare both. Btw, I don't understand your reasoning which consists to say that Ekiga puts deliberately private IP addresses in PDUs when the log says no. Again, to clearify my reasoning, these are the relevant observations: Firstly: Relevant -d 4 output of ekiga says the following when trying to connect to bluesip.net: rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0 SIP/2.0 479 Please don't use private IP addresses This suggests that there's a problem with the private IP address (192.168.1.36). Whether this is sip conform or not I dodn't know. Concerning to some people in some voip forums, it isn't. Secondly: This behavior is independent of using a STUN server or not and only appears when I am behind a NAT router. And thirdly: The fact that twinkle is able to connect to bluesip successfully from behind this specific router, suggests that this is no router-issue. Detailed traces of both ekiga and twinkle will follow. Chris Hi, I think a -d 4 trace and something from twinkle might really help Ekiga. When I tried from a machine with official internet access the line containing your rem=.. contained rem=udp$212.227.15.231:5060,local=udp$134.76.145.30:5060,if=134.76.145.30%eth0 but a few lines up: Contact: ;q=1, ;q=0.500 because the machine had a second interface to a local network. result from sip.1und1.de: SIP/2.0 403 Keine RFC1918-IPs erlaubt Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Cross-compiling ekiga for win32
Yes things have changed a week ago with "Split ekiga into an exec and helper libs". This has been done to make the Win32 version Ekiga-plugin capable, eventually. Am Mittwoch, den 08.07.2009, 11:28 +0200 schrieb Thierry Simonnet: > I don't have celt trouble for compiling. > make-2.patch and make-3.patch resolve all cross compile trouble for me > (Debian lenny). > > It is now possible to test a win32 version. > > Thanks a lot for your patches > > Jarmo Pussinen wrote: > > Michael Rickmann wrote: > > > >> As we cannot download the win32 subdir separately from git. Starting to > >> build Ekiga would change as follows. > >> Obtain Ekiga > >> git clone git://git.gnome.org/ekiga > >> Make a copy of the win32 directory > >> cp -a ekiga/win32 . > >> Change into that subdirectory, it will be your "BUILDROOT" > >> cd win32 > >> Get all the sources > >> make update-sources > >> Build Ekiga > >> make > >> The Makefile will try to move the already downloaded Ekiga to the right > >> place during the make update-sources. > >> > > > > Is this still the proper advice on how to build win32 version? > > > > I have installed mingw32 version that was mentioned in erlier mails, > > but I still get three errors. I kind of fixed them, but the resulting > > executable crashes on video call and on exit. > > > > I have attached the bug logs and my patches how I fixed them. > > (The patches are incremental and should be applied after each > > corresponding bug, because of the way the build script creates > > the source tree.) > > > > Especially the first bug seems weird in celt/configure: > > ./configure: line 12345: syntax error near unexpected token `tools="tools",' > > ./configure: line 12345: ` XIPH_PATH_OGG(tools="tools", tools="")' > > > > And I am sure that my fix replacing 'XIPH_PATH_OGG(tools="tools", > > tools="")' with 'tools="tools"' is not very good. > > > > The second bug is about undefined _win32_sysconfdir. > > > > And the third bug is about misplace ekiga-rc.o. > > > > The latter two I fixed in a reasonable manner (I hope) > > by adding libgmplatform.la to Makefile and by fixing ekiga-rc.o path > > in another Makefile. > > Could you test whether attached diff also works for you it is similar to yours with respect to the _win32_sysconfdir and fixes the ekiga-rc.o trouble right from the beginning. > > I cannot give much debug help about crashes, because starting > > Ekiga with command line "ekiga.exe -d 4" causes an additional > > command line window named > > c:\Program Files\Ekiga\plugins\h264_video_pwplugin_helper.exe > > to appear, but that window stays empty. > > > > Thanks > > jarmo > > 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. Regards Michael diff -ur src/ekiga/configure.ac ekiga/configure.ac --- src/ekiga/configure.ac 2009-07-03 14:11:30.0 +0200 +++ ekiga/configure.ac 2009-07-06 11:59:42.0 +0200 @@ -101,11 +101,9 @@ ;; mingw* ) -LT_PROG_RC - gm_platform="mingw" -CFLAGS="$CFLAGS -DSTATIC_LIBS_USED" -CXXFLAGS="$CXXFLAGS -DSTATIC_LIBS_USED" +CFLAGS="$CFLAGS -Wl,--enable-auto-import" +CXXFLAGS="$CXXFLAGS -Wl,--enable-auto-import" win32=1 ;; diff -ur src/ekiga/lib/engine/framework/Makefile.am ekiga/lib/engine/framework/Makefile.am --- src/ekiga/lib/engine/framework/Makefile.am 2009-07-06 07:23:07.0 +0200 +++ ekiga/lib/engine/framework/Makefile.am 2009-07-06 10:18:28.0 +0200 @@ -52,4 +52,5 @@ libgmframework_la_LDFLAGS = $(STACKLIB_LDFLAGS) libgmframework_la_LIBADD = \ $(top_builddir)/lib/gmconf/libgmconf.la \ + $(top_builddir)/lib/platform/libgmplatform.la \ $(SIGC_LIBS) $(GLIB_LIBS) $(XML_LIBS) diff -ur src/ekiga/lib/Makefile.am ekiga/lib/Makefile.am --- src/ekiga/lib/Makefile.am 2009-06-29 15:05:25.0 +0200 +++ ekiga/lib/Makefile.am 2009-07-06 10:18:28.0 +0200 @@ -22,10 +22,8 @@ libekiga_la_LDFLAGS = -export-dynamic libekiga_la_LIBADD = \ - gmconf/libgmconf.la \ gui/libgmwidgets.l
Re: [Ekiga-devel-list] Cross-compiling ekiga for win32
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@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Audio issues
Damien Sandras schrieb: Le mercredi 08 juillet 2009 à 12:18 -0400, Christian Schäfer a écrit : audio seems to be still a game of luck with current ekiga's stable release. Sometimes when I answer an incoming call, I can't hear the caller and he can't hear me. Sometimes I can hear him, sometimes I can't but he can. There doesn't seem to be any rule for this behavior. I observed this with all 3.2 versions. It's independent of the sip provider or the caller. All three audio devices are set to default, I have no sound daemon running (like esd or pulse). Ekiga, opal and ptlib are self-compiled on Ubuntu Linux. Once this problem occurs, I have to restart ekiga to get sound working again properly. I'll send a d4 output a soon this happens again. Anyone else having this problem? It sounds like NAT issues. No, this is independent of NAT. And if it wouldn't be, this problem should be reproducable then.. What is the cause then ? I would assume a NAT issue as well. There are routers which according to Ekiga's NAT detection change their role, my Fritz!Box e.g.. In the -d 4 logs look for the lines containing stun. When I am continously starting Ekiga and make calls Ekiga detects cone NAT. The first time or after some inactivity it reads port restricted NAT. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Christian Schäfer schrieb: Damien Sandras wrote: OK, first a few remarks : - having private IP addresses in SIP PDUs in perfectly legal and conform ; - in your logs, I see Ekiga puts both IP : private and public in the contact field, this is also legal and the sip registrar at lund1.de should not complain about it as there is also the public IP (with high priority as q=1) By the way, today I stumbled over an article in the current German's Linux Magazine issue, where a bunch of voip clients gets tested. They also observe this issue concerning the private IP address which makes it impossible to connect to some (german) providers like 1&1 and GMX with ekiga. Well, in a way these providers sell their phone numbers and they save money when they can not be used. But otherwise I cannot see any reason but achieving acceptance of standards why Ekiga - actually it seems Opal - behaves this way. I think trying with public and private IP first, if failure trying again with public only, if failure give in could be implemented. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga 3.2 on windows
Hi, thanks for your report. e schmidbauer schrieb: Hello, I downloaded the latest windows release of ekiga (3.2) from http://wwwuser.gwdg.de/~mrickma/ekiga/ I see that the CELT codec is included but when I use the CELT codec (32 & 48) to connect with a conference in freeswitch i get "Codec RAW Signed Linear (16 bit) decoder error!" Also when I try to call other extensions like voicemail, I get garbled sounds that don't make sense. I've seen the error: "Codec RAW Signed Linear (16 bit) decoder error!" before when compiling ekiga on linux and I believe it is caused by compiling ekiga with the improper celt distribution. I found that compiling ekiga with CELT 5.1 solved this problem. So I am wondering which distro of CELT you are using to compile ekiga with and has anyone else had this problem with the ekiga 3.2 on windows. Thanks. Actually I hooked in CELT because there was no problem cross compiling it from the latest git. As to the build you have used, it must have been very close to CELT 6.0. CELT 5.2 is the latest of the 5.x series. May be, keeping backwards compatibility is not that easy for the CELT developers when they have to keep an eye on forwards compatibility of their prior versions as well. What shall I do? Leave it out, no. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 Opal datasize, please help
I was stuck testing the latest changes to Ekiga since about 10 days.
Once a call to 5...@ekiga.net had been established windows were piling up
and rendered WinXP and Win7 unusable. Today I found the reason: commit
23036 to opal trunk which coresponds to 23028 opal v3_6 and is
contained in the archives needed by Ekiga 3.2.5.
Attached patch fixes this for ekiga head - it just reverses the opal
commit - no final solution. I am really no opal expert and a bit lost
here. Why has only Win32 been hit here?
Good news is that "Split ekiga into an exec and helper libs" - it
happend at about the same time as the opal change - seems to work for Win32.
Regards
Michael
diff -ur opal-23036/include/lids/lidep.h opal-23035/include/lids/lidep.h
--- opal-23036/include/lids/lidep.h 2009-07-12 20:23:54.0 +0200
+++ opal-23035/include/lids/lidep.h 2009-07-12 20:22:07.0 +0200
@@ -592,8 +592,7 @@
The default behaviour does nothing.
*/
virtual PBoolean SetDataSize(
- PINDEX dataSize, ///< New data size (in total)
- PINDEX frameSize ///< Individual frame size (if applicable)
+ PINDEX dataSize ///< New data size
);
/**Indicate if the media stream is synchronous.
diff -ur opal-23036/include/opal/mediastrm.h opal-23035/include/opal/mediastrm.h
--- opal-23036/include/opal/mediastrm.h 2009-07-12 20:23:54.0 +0200
+++ opal-23035/include/opal/mediastrm.h 2009-07-12 20:22:07.0 +0200
@@ -228,8 +228,7 @@
The default behaviour does nothing.
*/
virtual PBoolean SetDataSize(
- PINDEX dataSize, ///< New data size (in total)
- PINDEX frameSize ///< Individual frame size (if applicable)
+ PINDEX dataSize ///< New data size
);
/**Get the data size in bytes that is expected to be used. Some media
@@ -513,8 +512,7 @@
/**Set the data size in bytes that is expected to be used.
*/
virtual PBoolean SetDataSize(
- PINDEX dataSize, ///< New data size (in total)
- PINDEX frameSize ///< Individual frame size (if applicable)
+ PINDEX dataSize ///< New data size
);
/**Indicate if the media stream is synchronous.
@@ -734,8 +732,7 @@
The defafault simply sets teh member variable defaultDataSize.
*/
virtual PBoolean SetDataSize(
- PINDEX dataSize, ///< New data size (in total)
- PINDEX frameSize ///< Individual frame size (if applicable)
+ PINDEX dataSize ///< New data size
);
/**Indicate if the media stream is synchronous.
@@ -826,8 +823,7 @@
/** Override size of frame header is included
*/
virtual PBoolean SetDataSize(
- PINDEX dataSize, ///< New data size (in total)
- PINDEX frameSize ///< Individual frame size (if applicable)
+ PINDEX dataSize ///< New data size
);
/** Get the input device (e.g. for statistics)
diff -ur opal-23036/src/lids/lidep.cxx opal-23035/src/lids/lidep.cxx
--- opal-23036/src/lids/lidep.cxx 2009-07-12 20:23:54.0 +0200
+++ opal-23035/src/lids/lidep.cxx 2009-07-12 20:22:07.0 +0200
@@ -932,7 +932,7 @@
return false;
}
- SetDataSize(GetDataSize(), GetDataSize());
+ SetDataSize(GetDataSize());
PTRACE(3, "LineMedia\tStream opened for " << mediaFormat << ", using "
<< (notUsingRTP ? (useDeblocking ? "reblocked audio" : "audio frames") : "direct RTP"));
@@ -1101,13 +1101,13 @@
}
-PBoolean OpalLineMediaStream::SetDataSize(PINDEX /*dataSize*/, PINDEX frameSize)
+PBoolean OpalLineMediaStream::SetDataSize(PINDEX dataSize)
{
if (notUsingRTP) {
if (IsSource())
- useDeblocking = !line.SetReadFrameSize(frameSize) || line.GetReadFrameSize() != frameSize;
+ useDeblocking = !line.SetReadFrameSize(dataSize) || line.GetReadFrameSize() != dataSize;
else
- useDeblocking = !line.SetWriteFrameSize(frameSize) || line.GetWriteFrameSize() != frameSize;
+ useDeblocking = !line.SetWriteFrameSize(dataSize) || line.GetWriteFrameSize() != dataSize;
PTRACE(3, "LineMedia\tStream frame size: rd="
<< line.GetReadFrameSize() << " wr="
@@ -1115,8 +1115,7 @@
<< (useDeblocking ? "needs" : "no") << " reblocking.");
}
- // Yes we set BOTH to frameSize, and ignore the dataSize parameter
- return OpalMediaStream::SetDataSize(frameSize, frameSize);
+ return OpalMediaStream::SetDataSize(dataSize);
}
diff -ur opal-23036/src/opal/mediastrm.cxx opal-23035/src/opal/mediastrm.cxx
--- opal-23036/src/opal/mediastrm.cxx 2009-07-12 20:23:54.0 +0200
+++ opal-23035/src/opal/mediastrm.cxx 2009-07-12 20:22:07.0 +0200
@@ -389,15 +389,11 @@
}
-PBoolean OpalMediaStream::SetDataSize(PINDEX dataSize, PINDEX frameSize)
+PBoolean OpalMediaStream::SetDataSize(PINDEX dataSize)
{
if (dataSize <= 0)
return false;
- // Quantise data size
- if (frameSize > 1)
-dataSize = (dataSize+frameSize-1)/frameSize * frameSize;
-
PTRACE_IF(4, defaultDataSize != dataSize, "
Re: [Ekiga-devel-list] Win32 Opal datasize, please help
Am Montag, den 13.07.2009, 16:01 +0200 schrieb Damien Sandras: > Le dimanche 12 juillet 2009 à 22:40 +0200, Michael Rickmann a écrit : > > I was stuck testing the latest changes to Ekiga since about 10 days. > > Once a call to 5...@ekiga.net had been established windows were piling up > > and rendered WinXP and Win7 unusable. Today I found the reason: commit > > 23036 to opal trunk which coresponds to 23028 opal v3_6 and is > > contained in the archives needed by Ekiga 3.2.5. > > Attached patch fixes this for ekiga head - it just reverses the opal > > commit - no final solution. I am really no opal expert and a bit lost > > here. Why has only Win32 been hit here? > > Good news is that "Split ekiga into an exec and helper libs" - it > > happend at about the same time as the opal change - seems to work for Win32. > > Would you have a -d 4 output of the problem when it occurs without your > patch? > > Robert will examine it. > -- > _ Damien Sandras > (o- I will make some this evening. At the moment I have Linux only. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Opal datasize, please help
Damien Sandras schrieb: Le dimanche 12 juillet 2009 à 22:40 +0200, Michael Rickmann a écrit : I was stuck testing the latest changes to Ekiga since about 10 days. Once a call to 5...@ekiga.net had been established windows were piling up and rendered WinXP and Win7 unusable. Today I found the reason: commit 23036 to opal trunk which coresponds to 23028 opal v3_6 and is contained in the archives needed by Ekiga 3.2.5. Attached patch fixes this for ekiga head - it just reverses the opal commit - no final solution. I am really no opal expert and a bit lost here. Why has only Win32 been hit here? Good news is that "Split ekiga into an exec and helper libs" - it happend at about the same time as the opal change - seems to work for Win32. Would you have a -d 4 output of the problem when it occurs without your patch? Robert will examine it. Thanks a lot. I produced the -d 4 logs with my Win32 version of current Ekiga stable, i.e. Ekiga 3.2.5, Opal 3.6.4 and Ptlib 2.6.4. So commit 23028 to opal v3_6 seems to cause the error. The logs are rather long, you find them at http://wwwuser.gwdg.de/~mrickma/ekiga/data-size-logs.tar.gz. 5...@ekiganet-ekiga-killed-stderr.txt is when calling 5...@ekiga.net. As soon as the call was accepted empty windows were piling up and I had to kill Ekiga. fritzbox-nosound-ekiga-stderr.txt is when calling my audio-only SIP-phone-box at home. Ekiga told me that it was unable to open the audio driver, exit gracefully. The programs which I used can be found at http://wwwuser.gwdg.de/~mrickma : buggy-ekiga-setup-3.2.5-release.exe fails, ekiga-setup-3.2.5-release.exe is ok with patch reversed, ekiga_build-3.2.5.tgz documents how I built the stuff. Thanks again Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Opal datasize, please help
Damien Sandras schrieb: Le lundi 13 juillet 2009 à 23:32 +0200, Michael Rickmann a écrit : Damien Sandras schrieb: Le dimanche 12 juillet 2009 à 22:40 +0200, Michael Rickmann a écrit : I was stuck testing the latest changes to Ekiga since about 10 days. Once a call to 5...@ekiga.net had been established windows were piling up and rendered WinXP and Win7 unusable. Today I found the reason: commit 23036 to opal trunk which coresponds to 23028 opal v3_6 and is contained in the archives needed by Ekiga 3.2.5. Attached patch fixes this for ekiga head - it just reverses the opal commit - no final solution. I am really no opal expert and a bit lost here. Why has only Win32 been hit here? Good news is that "Split ekiga into an exec and helper libs" - it happend at about the same time as the opal change - seems to work for Win32. Would you have a -d 4 output of the problem when it occurs without your patch? Robert will examine it. Thanks a lot. I produced the -d 4 logs with my Win32 version of current Ekiga stable, i.e. Ekiga 3.2.5, Opal 3.6.4 and Ptlib 2.6.4. So commit 23028 to opal v3_6 seems to cause the error. The logs are rather long, you find them at http://wwwuser.gwdg.de/~mrickma/ekiga/data-size-logs.tar.gz. 5...@ekiganet-ekiga-killed-stderr.txt is when calling 5...@ekiga.net. As soon as the call was accepted empty windows were piling up and I had to kill Ekiga. fritzbox-nosound-ekiga-stderr.txt is when calling my audio-only SIP-phone-box at home. Ekiga told me that it was unable to open the audio driver, exit gracefully. The programs which I used can be found at http://wwwuser.gwdg.de/~mrickma : buggy-ekiga-setup-3.2.5-release.exe fails, ekiga-setup-3.2.5-release.exe is ok with patch reversed, ekiga_build-3.2.5.tgz documents how I built the stuff. Can you try with the following patch ? The error will stay, but we will have more information and you won't have windows popping up again and again. You will also have an indication of what the problem can be. Robert thinks the problem could be in Ekiga, but due to the API change. I applied the patch, the Windows went and Win32 Ekiga is better than it ever was. The large audio delay (> 1.5 sec) is nearly gone, must have been the changes to Opal. However, as you said, the error stayed - somehow I like it, audio is next to perfect. In the logs we get now lines saying Media Patch:3096 GMAudioInputManager_ptlib Encountered error while trying to read data, read 160 instead of 320 The complete -d 4 log you find at http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-stderr.txt.gz . Attached backtrace shows what happens when calling 5...@ekiga.net and where the request for 320 comes from. Thanks for the help so far. Michael (gdb) Num Type Disp Enb AddressWhat 1 breakpoint keep y 0x00488564 in GMAudioInputManager_ptlib::get_frame_data(char*, unsigned int, unsigned int&) at ../../../../lib/engine/components/ptlib/audioinput-manager-ptlib.cpp:186 breakpoint already hit 2 times (gdb) Continuing. (gdb) Continuing. [New thread 2020.0x4f4] [New thread 2020.0x190] [New thread 2020.0xe88] [New thread 2020.0xbd4] warning: Lowest section in C:\WINDOWS\system32\mfc42loc.dll is .rsrc at 61dc1000 [New thread 2020.0x9b8] [New thread 2020.0x748] [New thread 2020.0x9bc] [New thread 2020.0x7c4] [New thread 2020.0xac4] [New thread 2020.0xcfc] [New thread 2020.0x4b0] [New thread 2020.0x538] [New thread 2020.0x870] [New thread 2020.0xa24] [New thread 2020.0xac8] [New thread 2020.0xc54] [New thread 2020.0xf48] [New thread 2020.0x4e8] [New thread 2020.0xd24] [New thread 2020.0x9b4] [New thread 2020.0x74c] [New thread 2020.0xd34] [New thread 2020.0xd04] [New thread 2020.0x600] [New thread 2020.0xd00] [Switching to thread 2020.0x9b4] Breakpoint 1, GMAudioInputManager_ptlib::get_frame_data (this=0x8429580, data=0x8439c74 "", size=320, bytes_read=0xc95fe14) at ../../../../lib/engine/components/ptlib/audioinput-manager-ptlib.cpp:186 186 ../../../../lib/engine/components/ptlib/audioinput-manager-ptlib.cpp: No such file or directory. in ../../../../lib/engine/components/ptlib/audioinput-manager-ptlib.cpp Current language: auto; currently c++ (gdb) #0 GMAudioInputManager_ptlib::get_frame_data (this=0x8429580, data=0x8439c74 "", size=320, bytes_read=0xc95fe14) at ../../../../lib/engine/components/ptlib/audioinput-manager-ptlib.cpp:186 #1 0x00444bba in Ekiga::AudioInputCore::get_frame_data (this=0x83e3eb8, data=0x8439c74 "", size=320, bytes_read=0xc95fe14) at ../../../lib/engine/audioinput/audioinput-core.cpp:374 #2 0x0048b68b in PSoundChannel_EKIGA::Read (this=0x8435198, buf=0x8439c74, len=320) at ../../../../lib/engine/components/opal/opal-audio.cpp:176 #3 0x0054eecf in OpalRawMediaStream::ReadData (this=0xa562588, buffer=0x8439c74 "", size=320, leng...@0xc95fe80) a
Re: [Ekiga-devel-list] Win32 Opal datasize, please help
Am Dienstag, den 14.07.2009, 23:09 +0200 schrieb Damien Sandras: > Le mardi 14 juillet 2009 à 18:06 +0200, Michael Rickmann a écrit : > > Damien Sandras schrieb: > > > Le lundi 13 juillet 2009 à 23:32 +0200, Michael Rickmann a écrit : > > >> Damien Sandras schrieb: > > >>> Le dimanche 12 juillet 2009 à 22:40 +0200, Michael Rickmann a écrit : snip > > >> http://wwwuser.gwdg.de/~mrickma/ekiga/data-size-logs.tar.gz. > > >> 5...@ekiganet-ekiga-killed-stderr.txt is when calling 5...@ekiga.net. As > > >> soon as the call was accepted empty windows were piling up and I had to > > >> kill Ekiga. fritzbox-nosound-ekiga-stderr.txt is when calling my > > >> audio-only SIP-phone-box at home. Ekiga told me that it was unable to > > >> open the audio driver, exit gracefully. The programs which I used can be > > >> found at http://wwwuser.gwdg.de/~mrickma : > > >> buggy-ekiga-setup-3.2.5-release.exe fails, ekiga-setup-3.2.5-release.exe > > >> is ok with patch reversed, ekiga_build-3.2.5.tgz documents how I built > > >> the stuff. > > > > > > Can you try with the following patch ? > > > The error will stay, but we will have more information and you won't > > > have windows popping up again and again. > > > > > > You will also have an indication of what the problem can be. > > > > > > Robert thinks the problem could be in Ekiga, but due to the API change. > > > > > > > > I applied the patch, the Windows went and Win32 Ekiga is better than it > > ever was. The large audio delay (> 1.5 sec) is nearly gone, must have > > been the changes to Opal. However, as you said, the error stayed - > > somehow I like it, audio is next to perfect. In the logs we get now > > lines saying > > Media Patch:3096GMAudioInputManager_ptlib Encountered error while > > trying to read data, read 160 instead of 320 > > The complete -d 4 log you find at > > http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-stderr.txt.gz . > > Attached backtrace shows what happens when calling 5...@ekiga.net and > > where the request for 320 comes from. > > Thanks for the help so far. > > Michael > > The purpose of that fix (from Robert) was to improve the audio quality. > > Now, even if it works, we need to determine where those 320 and 160 > values come from and which one is correct (I suppose 160 is correct as > it works). > -- > _ Damien Sandras Yes,, I also think 160 is correct. From the -d 4 log: Pool:2872 Media Clamping audio stream frame size from 16 to minimum 160 Pool:2872 Media Audio source data size set to 160 bytes and 20 buffers. Pool:2872 Media Set data size from 16 to 320 Pool:2872 AudioInputCore Setting stream buffer size 20/160 Pool:2872 GMAudioInputManager_ptlib Setting buffer size to 160/20 Pool:2872 WinSnd Setting sounds buffers to 20 x 160 Pool:2872 PCSSAdding filters to patch This evening, I will look where this "Media Set data size from 16 to 320" comes from, I guess Opal. Ekiga does not set any data sizes, does it? Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Opal datasize, please help
Damien Sandras schrieb:
Le mercredi 15 juillet 2009 à 08:52 +0200, Michael Rickmann a écrit :
Am Dienstag, den 14.07.2009, 23:09 +0200 schrieb Damien Sandras:
Le mardi 14 juillet 2009 à 18:06 +0200, Michael Rickmann a écrit :
Damien Sandras schrieb:
Le lundi 13 juillet 2009 à 23:32 +0200, Michael Rickmann a écrit :
Damien Sandras schrieb:
Le dimanche 12 juillet 2009 à 22:40 +0200, Michael Rickmann a écrit :
snip
http://wwwuser.gwdg.de/~mrickma/ekiga/data-size-logs.tar.gz.
5...@ekiganet-ekiga-killed-stderr.txt is when calling 5...@ekiga.net. As
soon as the call was accepted empty windows were piling up and I had to
kill Ekiga. fritzbox-nosound-ekiga-stderr.txt is when calling my
audio-only SIP-phone-box at home. Ekiga told me that it was unable to
open the audio driver, exit gracefully. The programs which I used can be
found at http://wwwuser.gwdg.de/~mrickma :
buggy-ekiga-setup-3.2.5-release.exe fails, ekiga-setup-3.2.5-release.exe
is ok with patch reversed, ekiga_build-3.2.5.tgz documents how I built
the stuff.
Can you try with the following patch ?
The error will stay, but we will have more information and you won't
have windows popping up again and again.
You will also have an indication of what the problem can be.
Robert thinks the problem could be in Ekiga, but due to the API change.
I applied the patch, the Windows went and Win32 Ekiga is better than it
ever was. The large audio delay (> 1.5 sec) is nearly gone, must have
been the changes to Opal. However, as you said, the error stayed -
somehow I like it, audio is next to perfect. In the logs we get now
lines saying
Media Patch:3096 GMAudioInputManager_ptlib Encountered error while
trying to read data, read 160 instead of 320
The complete -d 4 log you find at
http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-stderr.txt.gz .
Attached backtrace shows what happens when calling 5...@ekiga.net and
where the request for 320 comes from.
Thanks for the help so far.
Michael
The purpose of that fix (from Robert) was to improve the audio quality.
Now, even if it works, we need to determine where those 320 and 160
values come from and which one is correct (I suppose 160 is correct as
it works).
--
_ Damien Sandras
Yes,, I also think 160 is correct. From the -d 4 log:
Pool:2872 Media Clamping audio stream frame size from 16 to minimum 160
Pool:2872 Media Audio source data size set to 160 bytes and 20 buffers.
Pool:2872 Media Set data size from 16 to 320
Pool:2872 AudioInputCore Setting stream buffer size 20/160
Pool:2872 GMAudioInputManager_ptlib Setting buffer size to 160/20
Pool:2872 WinSnd Setting sounds buffers to 20 x 160
Pool:2872 PCSSAdding filters to patch
This evening, I will look where this "Media Set data size from 16 to
320" comes from, I guess Opal. Ekiga does not set any data sizes, does
it?
I don't think so, but I'm not 100% sure. I have read through the code
yesterday too.
Well it all condenses down to line opal-3.6.4/src/opal/patch.cxx:217
which is
source.SetDataSize(sink->primaryCodec->GetOptimalDataFrameSize(true),
sourceFormat.GetFrameSize());
Opal's ***"dataSize"***, which we are called with in
"ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp :
GMAudioInputManager_ptlib::get_frame_data : size" is derived from the
GetOptimalDataFrameSize(true) part.
In our GMAudioInputManager_ptlib::set_buffer_size : buffer_size we are
confronted with Opal's ***"frameSize"*** which is derived from
sourceFormat.GetFrameSize() (see above). Opal makes shure that
***"dataSize"*** is a multiple of ***"frameSize"***.
As Ekiga must not know about Opal's internals in
GMAudioInputManager_ptlib::get_frame_data we are supposed to read
as many buffers as needed for size (see GetOptimalDataFrameSize(true)
above).
Could you make sure whether the interpretation of the new API to read as
many buffers to fullfill the size arggument of "PBoolean
OpalRawMediaStream::ReadData(BYTE * buffer, PINDEX size, PINDEX &
length)" is correct?
If so I would suggest something like attached patch - I have only tested
it under Win7-RC. The shortening of Win32 audio latency presumably
achieved by the change in Opal stays. Eventually, I think Linux and
Win32 could share the code at this place.
Michael
diff -ur ekiga-3.2.5.orig/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp
--- ekiga-3.2.5.orig/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp 2009-07-15 18:37:09.0 +0200
+++ ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp 2009-07-15 19:37:57.0 +0200
@@ -47,7 +47,7 @@
{
current_state.opened = false;
input_device = NULL;
- expectedFrameSize = 0;
+ internalFrameSize = 0;
}
GMAudioInputManager_ptlib::~GMA
Re: [Ekiga-devel-list] Win32 Opal datasize, please help
Damien Sandras schrieb: Michael, Le mercredi 15 juillet 2009 à 21:47 +0200, Michael Rickmann a écrit : [...] Well it all condenses down to line opal-3.6.4/src/opal/patch.cxx:217 which is source.SetDataSize(sink->primaryCodec->GetOptimalDataFrameSize(true), sourceFormat.GetFrameSize()); Opal's ***"dataSize"***, which we are called with in "ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp : GMAudioInputManager_ptlib::get_frame_data : size" is derived from the GetOptimalDataFrameSize(true) part. In our GMAudioInputManager_ptlib::set_buffer_size : buffer_size we are confronted with Opal's ***"frameSize"*** which is derived from sourceFormat.GetFrameSize() (see above). Opal makes shure that ***"dataSize"*** is a multiple of ***"frameSize"***. As Ekiga must not know about Opal's internals in GMAudioInputManager_ptlib::get_frame_data we are supposed to read as many buffers as needed for size (see GetOptimalDataFrameSize(true) above). Could you make sure whether the interpretation of the new API to read as many buffers to fullfill the size arggument of "PBoolean OpalRawMediaStream::ReadData(BYTE * buffer, PINDEX size, PINDEX & length)" is correct? This patch should fix the problem: http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=rev&revision=23106 However, I'm not sure any patch is still required in Ekiga. In any case, I will probably remove the check for the read/expected data in Ekiga. But first, could you test the above patch without any modification in Ekiga and tell me if it works better ? Thank you, PS: the above patch is for TRUNK, not STABLE, but it should be backported easily. I will have to check more carefully tomorrow evening. The first test Ekiga master without modification with Opal head (23107, one more than you indicated) failed, due to not being able to open the audio device in Ekiga under Win7. I will try with the stable stuff tomorrow. Thanks Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Opal datasize, please help
Damien Sandras schrieb:
Michael,
Le mercredi 15 juillet 2009 à 21:47 +0200, Michael Rickmann a écrit :
[...]
[...]
This patch should fix the problem:
http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=rev&revision=23106
However, I'm not sure any patch is still required in Ekiga.
In any case, I will probably remove the check for the read/expected data
in Ekiga.
But first, could you test the above patch without any modification in
Ekiga and tell me if it works better ?
Thank you,
PS: the above patch is for TRUNK, not STABLE, but it should be
backported easily.
Last night I was fooling myself after having taken out all patches.
I applied the Opal commit as a patch to Ekiga stable (attached for
easier reference). Apparently Opal respects now what we have read and
continues until it has all the data it wants. The first test without
patch to Ekiga resulted in piling up Windows again.
So I made a new patch (ekiga_framesize.diff, attached) which is far less
obtrusive than the last one. It reutilizes expectedFrameSize which was
unused in Ekiga to do a bit of checking, though it may have different
semantics now. We have to check for data != 0 and size != 0 as Opal may
send that through. The Ekiga::Runtime::run_in_main...AI_ERROR_READ we
certainly do not want for Win32.
The overall result is really good. Audio latency when calling
5...@ekiga.net is small, less than 1/2 sec. Video is almost simultaneous
when tapping the microphone. At least I could not determine whether it
was faster or slower than audio.
Thanks for your help.
Michael
diff -x .svn -ur opal-23105/src/opal/mediastrm.cxx opal-23106/src/opal/mediastrm.cxx
--- opal-23105/src/opal/mediastrm.cxx 2009-07-17 07:30:33.0 +0200
+++ opal-23106/src/opal/mediastrm.cxx 2009-07-17 14:57:42.0 +0200
@@ -740,13 +740,21 @@
if (!IsOpen() || m_channel == NULL)
return false;
- if (!m_channel->Read(buffer, size))
-return false;
+ if (buffer == NULL || size == 0)
+return m_channel->Read(buffer, size);
+
+ while (size > 0) {
+if (!m_channel->Read(buffer, size))
+ return false;
+
+PINDEX lastReadCount = m_channel->GetLastReadCount();
+CollectAverage(buffer, lastReadCount);
- length = m_channel->GetLastReadCount();
+buffer += lastReadCount;
+length += lastReadCount;
+size -= lastReadCount;
+ }
- if (buffer != NULL)
-CollectAverage(buffer, length);
return true;
}
diff -ur ekiga-3.2.5.orig/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp
--- ekiga-3.2.5.orig/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp 2009-07-17 17:07:45.0 +0200
+++ ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp 2009-07-17 17:10:39.0 +0200
@@ -160,8 +160,10 @@
{
PTRACE(4, "GMAudioInputManager_ptlib\tSetting buffer size to " << buffer_size << "/" << num_buffers);
- if (input_device)
+ if (input_device) {
input_device->SetBuffers (buffer_size, num_buffers);
+expectedFrameSize = buffer_size;
+ }
}
@@ -172,6 +174,11 @@
bool ret = false;
bytes_read = 0;
+ if (data == NULL || size == 0) {
+PTRACE(1, "GMAudioInputManager_ptlib\tError, will not read " << size << " bytes to buffer at " << data);
+return false;
+ }
+
if (!current_state.opened) {
PTRACE(1, "GMAudioInputManager_ptlib\tTrying to get frame from closed device");
return false;
@@ -182,9 +189,11 @@
if (ret) {
bytes_read = input_device->GetLastReadCount();
}
-if (bytes_read != size) {
- PTRACE(1, "GMAudioInputManager_ptlib\tEncountered error while trying to read data");
+if (bytes_read < expectedFrameSize) {
+ PTRACE(1, "GMAudioInputManager_ptlib\tError while trying to read data, read " << bytes_read << " instead of expected " << expectedFrameSize);
+#ifndef WIN32
Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMAudioInputManager_ptlib::device_error_in_main), current_state.device, Ekiga::AI_ERROR_READ));
+#endif
}
}
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 UTF-8 vs. Codepage or what so ever
Ekiga's handling of Windows file names and device names is done mostly
in UTF-8 which works as long as there are no national characters in the
names. I have a German Windows and a USB headset which in Ekiga shows up
as "USB-Ger" instead of "USB-Gerät" (USB device). Ok, I can click
Ekiga's update devices and then there is a "USB-Gerät" which I can
select thanks to the g_locale_to_utf8 support in
ekiga/lib/gui/gmpreferences.c. However, the next time Ekiga is started
it complains because it is unable to open the "USB-Ger".
I tried a similar approach as Eugen did when fixing bug #575907 (git
c9aedde44825, 2009-04-21). But similar changes at the level of
lib/components/ptlib device managers using g_locale_to_utf8 and back
would not work for Windows. Presumably some library calls have been in
between. For Win32 Ekiga the separation of (UTF-8) vs. (Codepage) with
respect to Ptlib's device names is
(GUI + gconf) vs. (C-library + device strings).
A good place to convert the device strings to UTF-8 is
gm_prefs_window_convert_string_list in ekiga/src/gui/preferences.cpp.
Conversion from UTF-8 can only be done where we know that it is a device
string, i. e. in the device gmconf-bridges. I have prepared three
patches and tested them under Windows and for adverse effects also Linux.
ekiga01_filename.diff is not so important but easy. It allows special
characters in the sound files. It shows the principle of converting from
UTF-8, i.e having a specialized routine in lib/gmconf/gmconf-glib.c
which is called for WIN32 from audiooutput-gmconf-bridge.cpp.
ekiga02_devstring.diff involves quite a few files. It does the device
string conversions summarized above.
ekiga03_isutf8.diff cleans up ekiga/lib/gui/gmpreferences.c. Linux is
completely UTF-8 and for Win32 we have done the conversion to UTF-8 with
the second patch earlier. Moreover double conversion to UTF-8 does not
work when there are any special characters.
In some parts the patches seem a bit bulky. Do you have any idea how to
solve the device string issue for Win32 in a more elegant way?
Regards
Michael
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-gmconf-bridge.cpp ekiga/lib/engine/audiooutput/audiooutput-gmconf-bridge.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-gmconf-bridge.cpp 2009-07-16 14:24:01.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-gmconf-bridge.cpp 2009-07-16 13:49:41.0 +0200
@@ -131,7 +131,7 @@
(key == SOUND_EVENTS_KEY "enable_busy_tone_sound") ) {
gchar *c_file_name = NULL;
-c_file_name = gm_conf_get_string (SOUND_EVENTS_KEY "busy_tone_sound");
+c_file_name = GM_CONF_GET_FILE_NAME (SOUND_EVENTS_KEY "busy_tone_sound");
if (c_file_name == NULL) {
PTRACE(1, "AudioOutputCoreConfBridge\t" << SOUND_EVENTS_KEY "busy_tone_sound" << " is NULL");
return;
@@ -148,7 +148,7 @@
(key == SOUND_EVENTS_KEY "enable_incoming_call_sound") ) {
gchar *c_file_name = NULL;
-c_file_name = gm_conf_get_string (SOUND_EVENTS_KEY "incoming_call_sound");
+c_file_name = GM_CONF_GET_FILE_NAME (SOUND_EVENTS_KEY "incoming_call_sound");
if (c_file_name == NULL) {
PTRACE(1, "AudioOutputCoreConfBridge\t" << SOUND_EVENTS_KEY "incoming_call_sound" << " is NULL");
return;
@@ -165,7 +165,7 @@
(key == SOUND_EVENTS_KEY "enable_new_message_sound") ) {
gchar *c_file_name = NULL;
-c_file_name = gm_conf_get_string (SOUND_EVENTS_KEY "new_message_sound");
+c_file_name = GM_CONF_GET_FILE_NAME (SOUND_EVENTS_KEY "new_message_sound");
if (c_file_name == NULL) {
PTRACE(1, "AudioOutputCoreConfBridge\t" << SOUND_EVENTS_KEY "new_message_sound" << " is NULL");
return;
@@ -183,7 +183,7 @@
(key == SOUND_EVENTS_KEY "enable_new_voicemail_sound") ) {
gchar *c_file_name = NULL;
-c_file_name = gm_conf_get_string (SOUND_EVENTS_KEY "new_voicemail_sound");
+c_file_name = GM_CONF_GET_FILE_NAME (SOUND_EVENTS_KEY "new_voicemail_sound");
if (c_file_name == NULL) {
PTRACE(1, "AudioOutputCoreConfBridge\t" << SOUND_EVENTS_KEY "new_voicemail_sound" << " is NULL");
return;
@@ -200,7 +200,7 @@
(key == SOUND_EVENTS_KEY "enable_ring_tone_sound") ) {
gchar *c_file_name = NULL;
-c_file_name = gm_conf_get_string (SOUND_EVENTS_KEY "ring_tone_sound");
+c_file_name = GM_CONF_GET_FILE_NAME (SOUND_EVENTS_KEY "ring_tone_sound");
if (c_file_name == NULL) {
PTRACE(1, "AudioOutputCoreConfBridge\t" << SOUND_EVENTS_KEY "ring_tone_sound" << " is NULL");
return;
diff -ur ekiga.orig/lib/gmconf/gmconf-glib.c ekiga/lib/gmconf/gmconf-glib.c
--- ekiga.orig/lib/gmconf/gmconf-glib.c 2009-07-16 14:24:01.0 +0200
+++ ekiga/lib/gmconf/gmconf-glib.c 2009-07-16 14:26:12.0 +0200
@@ -1564,6 +1564,24 @@
return string_list_deep_copy (entry_get_list (entry));
}
+#ifdef WIN32
+gchar *
+gm_conf_get_file_name(const gchar *key)
+{
+ gchar *utf8_str;
+ gchar
[Ekiga-devel-list] Win32 Ekiga stable branch
I am trying to prepare a Win32 version of Ekiga 3.2.5 for ekiga.org and realized that I had to pick a few items from Opal HEAD and Ekiga master. For Ekiga I think that the following Win32 commits are safe to be merged into stable from where they can be picked up for the next release. 2009-06-29 daf4ff1f453 Made stdout/stderr work correctly under windows 7 2009-06-29 bcc4e157610 Updated the win32 installer so ekiga isn't 2009-06-29 10d293e6bed Made so the linker doesn't find main on win32 If you agree, do you need any extra patches for that? Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 Ekiga 3.2.5 preview
available at http://wwwuser.gwdg.de/~mrickma/ekiga/ . They are the files containing 3.2.5 . I think that is about what I can achieve at the moment. Refinements will follow. Please test!! If you do not have Windows, free some 30 -50G partition on one of your disks, google for "Windows 7" (I think MS is doing a good job now), get it, install it, convince grub to start it (may be tricky), install Ekiga and test. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Christian Schäfer schrieb:
Eugen Dedu wrote:
I see a commit in opal which might interest you:
2009-07-13 06:33 rjongbloed
* src/sip/handlers.cxx: Added special case of m_contactAddress *=
"%LIMITED" for SIP registration which will only fill the
"Contact" field of the REGISTER command with addresses that are
on the same interface as where the packet is being sent.
This is to address STUPID registrars that refuse the entire
registration when extra contact addresses are included that it
doesn't like, e.g. the private address. Correct behaviour is to
return what it DOES like, not refuse registration completely.
Thanks Eugen. That sounds indeed very interesting.
Chris
___
Yes opal is providing a possibility for handling this kind of brain-dead
provider now. Only Ekiga has to pick it up. Since ekiga.net is serviced
I worked against the aliens - patch is attached. What it does it lets
Ekiga try twice to register, the second time setting %LIMITED. Or if you
know before that you have a limited provider you can put the string
%limit into the name of your account and Ekiga will succeed without
retry. I tried under Linux only and only with sip.1und1.de with which
Ekiga could not register before. Now it works.
Michael
diff -ur src/ekiga/lib/engine/components/opal/opal-account.cpp ekiga/lib/engine/components/opal/opal-account.cpp
--- src/ekiga/lib/engine/components/opal/opal-account.cpp 2009-07-16 17:30:46.0 +0200
+++ ekiga/lib/engine/components/opal/opal-account.cpp 2009-07-19 12:10:14.0 +0200
@@ -127,6 +127,8 @@
type = Account::SIP;
else
type = Account::H323;
+
+ limited = (name.find ("%limit") != std::string::npos);
}
@@ -301,6 +303,12 @@
}
+bool Opal::Account::is_limited () const
+{
+ return limited;
+}
+
+
bool Opal::Account::is_active () const
{
return enabled;
@@ -494,10 +502,16 @@
case RegistrationFailed:
-status = _("Could not register");
-if (!info.empty ())
- status = status + " (" + info + ")";
-updated.emit ();
+if (!limited) {
+ limited = true;
+ gmref_ptr endpoint = core.get ("opal-sip-endpoint");
+ endpoint->subscribe (*this);
+} else {
+ status = _("Could not register");
+ if (!info.empty ())
+status = status + " (" + info + ")";
+ updated.emit ();
+}
break;
case Processing:
diff -ur src/ekiga/lib/engine/components/opal/opal-account.h ekiga/lib/engine/components/opal/opal-account.h
--- src/ekiga/lib/engine/components/opal/opal-account.h 2009-07-16 17:30:46.0 +0200
+++ ekiga/lib/engine/components/opal/opal-account.h 2009-07-19 12:10:37.0 +0200
@@ -128,6 +128,8 @@
bool is_enabled () const;
+bool is_limited () const;
+
bool is_active () const;
void remove ();
@@ -160,6 +162,7 @@
RegistrationState state;
bool dead;
bool enabled;
+bool limited;
unsigned timeout;
std::string aid;
std::string name;
diff -ur src/ekiga/lib/engine/components/opal/sip-endpoint.cpp ekiga/lib/engine/components/opal/sip-endpoint.cpp
--- src/ekiga/lib/engine/components/opal/sip-endpoint.cpp 2009-07-16 17:30:46.0 +0200
+++ ekiga/lib/engine/components/opal/sip-endpoint.cpp 2009-07-19 12:17:59.0 +0200
@@ -82,6 +82,7 @@
account.get_authentication_username (),
account.get_password (),
account.is_enabled (),
+ account.is_limited (),
account.get_timeout ());
} else {
@@ -574,6 +575,7 @@
const std::string auth_username,
const std::string password,
bool is_enabled,
+ bool is_limited,
unsigned timeout)
{
PWaitAndSignal mut(listsMutex);
@@ -592,6 +594,8 @@
SIPRegister::Params params;
params.m_addressOfRecord = aor.str ();
params.m_registrarAddress = host;
+ if (is_limited)
+params.m_contactAddress = "%LIMITED";
params.m_authID = auth_username;
params.m_password = password;
params.m_expire = is_enabled ? timeout : 0;
diff -ur src/ekiga/lib/engine/components/opal/sip-endpoint.h ekiga/lib/engine/components/opal/sip-endpoint.h
--- src/ekiga/lib/engine/components/opal/sip-endpoint.h 2009-07-16 17:30:46.0 +0200
+++ ekiga/lib/engine/components/opal/sip-endpoint.h 2009-07-19 12:15:49.0 +0200
@@ -160,6 +160,7 @@
const std::string auth_username,
const std::string password,
bool is_enabled,
+ bool is_limited,
unsigned timeout);
void OnRegistered (const PString & aor,
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Christian Schäfer schrieb: Michael Rickmann wrote: Yes opal is providing a possibility for handling this kind of brain-dead provider now. Only Ekiga has to pick it up. Since ekiga.net is serviced I worked against the aliens - patch is attached. What it does it lets Ekiga try twice to register, the second time setting %LIMITED. Or if you know before that you have a limited provider you can put the string %limit into the name of your account and Ekiga will succeed without retry. I tried under Linux only and only with sip.1und1.de with which Ekiga could not register before. Now it works. Michael Great, thanks Michael. Is this change available through svn? I'll give it try. Chris Yes, svn co https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/opal/trunk src/opal -r HEAD in one line or 23104 instead of HEAD. My patch is against Ekiga master only so you need a recent version there as well. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 UTF-8 vs. Codepage or what so ever
Am Samstag, den 18.07.2009, 21:54 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Ekiga's handling of Windows file names and device names is done mostly > > in UTF-8 which works as long as there are no national characters in the > > names. I have a German Windows and a USB headset which in Ekiga shows up > > as "USB-Ger" instead of "USB-Gerät" (USB device). Ok, I can click > > Ekiga's update devices and then there is a "USB-Gerät" which I can > > select thanks to the g_locale_to_utf8 support in > > ekiga/lib/gui/gmpreferences.c. However, the next time Ekiga is started > > it complains because it is unable to open the "USB-Ger". > > Hi Michael, > > Until one month ago, linux usb subsystem have gotten the device name, > translated it from utf-16 to latin-1 and give device names as latin-1 to > applications. > > The > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a853a3d4eb2edb066248a39f0634f6f5858816a0 > > commit changes that, so starting with 2.6.31 my ekiga patch should be > removed (or make #ifdef linuxversion <= 2.6.30...) > Hi Eugen, I rechecked what I had done before and found that your patch with the lib/engine/components/ptlib/utils.cpp and other files indeed works for WIN32 as well, if you use g_locale_to_utf8 and g_locale_from_utf8. I must have done some thing wrong the first time I tried. So my new second patch even simplifies the code, it is tested for head and stable. > In the original ubuntu bug report, someone with such a camera and under > windows had no problem. In fact, I was told that windows gives device > names already in utf-8. > > If I understand you correctly, this is not the case for you?! That would make it really complicated then Windows would sometimes do and sometimes not. Take the entry in ekiga.conf (WIN32 database) USB-Audiogerät (PTLIB/WindowsMultimedia) This is under a german XP - Win7 is slightly different but also contains the ...gerät. This is Window's description for a generic USB audio device. So the problem is not in the string returned by the device but in Window's wording around it. And above is how Ekiga should handle it. Without attached patch the string would get truncated to: USB-Audioger. Ptlib will never find it. > > > I tried a similar approach as Eugen did when fixing bug #575907 (git > > c9aedde44825, 2009-04-21). But similar changes at the level of > > lib/components/ptlib device managers using g_locale_to_utf8 and back > > would not work for Windows. Presumably some library calls have been in > > between. For Win32 Ekiga the separation of (UTF-8) vs. (Codepage) with See above, I have been wrong here, it works! > > respect to Ptlib's device names is > > (GUI + gconf) vs. (C-library + device strings). > > In linux, it's the same to my knowledge. Good to know, though I think that quite a lot locales for which the C-library is generated are UTF-8. > > I think that in ekiga storing in locale in gconf entries was a very old > code, which should now be removed, is that right (your third patch)? > I think that for Windows gconf entries were always stored as UTF-8. That is what the database we use was made for. As the code is used when you press the update button it should use device names freshly read from ptlib. I interpret it as a punctual attempt to get things right. Without my patch it is the only place where localized devices show up in Windows. When the conversion has been done already as it has been done for Linux and should be done for Windows, this code messes up special characters and it should be removed > > A good place to convert the device strings to UTF-8 is > > gm_prefs_window_convert_string_list in ekiga/src/gui/preferences.cpp. > > Conversion from UTF-8 can only be done where we know that it is a device > > string, i. e. in the device gmconf-bridges. I have prepared three > > patches and tested them under Windows and for adverse effects also Linux. Still good places but leads to bulky code. > > > > ekiga01_filename.diff is not so important but easy. It allows special > > characters in the sound files. It shows the principle of converting from > > UTF-8, i.e having a specialized routine in lib/gmconf/gmconf-glib.c > > which is called for WIN32 from audiooutput-gmconf-bridge.cpp. Still a wish of mine, code is not too unelegant. > > > ekiga02_devstring.diff involves quite a few files. It does the device > > string conversions summarized above. Has been superseeded by ekiga02_codepage.diff now. > > > > ekiga03_isutf8.diff cleans up ekiga/lib/gui/gmpreferences.c. Linux is > > completely UTF-8 and for Win32 we have done the convers
[Ekiga-devel-list] Win32 Vista terminate problem
I have a Vista notebook available for three days only. As already reported Ekiga has to be killed at shutdown. It seems a pecularity of Vista which can be overcome by several means. if (Vista) 1) Wait at the end of the main thread ca. 5 secs, or 2) do Wait 100 msec, enumerate Ekiga's threads while (num_threads > 1) The second possibility seems cleaner but is more work and will not look nice. What shall I do? Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Vista terminate problem
Damien Sandras schrieb: Le mercredi 22 juillet 2009 à 19:49 +0200, Michael Rickmann a écrit : I have a Vista notebook available for three days only. As already reported Ekiga has to be killed at shutdown. It seems a pecularity of Vista which can be overcome by several means. if (Vista) 1) Wait at the end of the main thread ca. 5 secs, or 2) do Wait 100 msec, enumerate Ekiga's threads while (num_threads > 1) The second possibility seems cleaner but is more work and will not look nice. What shall I do? Do we have a bt to know why it deadlocks? Most probably Robert can give us a hint in that case... Yes, any deeper knowlege would be helpful here. At the moment I am poking around. So far I found out that it is just a matter of time. If I put a MessageBox which you have to click at the end of the Windows code Ekiga terminates under Vista properly. XP and 7Ultimate do not need that. The overall picture is that Ekiga's main thread exits and ptlib and opal are supposed to clean up their threads. The last one is the ptlib housekeeper thread. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] New stable release
Am Montag, den 27.07.2009, 20:55 +0200 schrieb Eugen Dedu:
> Christian Schäfer wrote:
> >> We plan to make a new release. Until now, there has been:
> >
> > I'd love to see the workaround for picky registrars as well in this
> > release.
>
> Me too.
>
> --
> Eugen
> ___
Sorry for not being very resposive at the moment. I am still trying to
get something meaningful out of the Vista shutdown.
The alien registrar patch which I submitted does not apply well to
stable. For stable I use a different one (attached) which lacks the "try
twice" feature. So you have to have the string %limit in the account
name.
Michael
diff -ur ekiga-3.2.5.orig/lib/engine/components/opal/opal-account.cpp ekiga-3.2.5/lib/engine/components/opal/opal-account.cpp
--- ekiga-3.2.5.orig/lib/engine/components/opal/opal-account.cpp 2009-07-19 17:40:21.0 +0200
+++ ekiga-3.2.5/lib/engine/components/opal/opal-account.cpp 2009-07-19 17:53:19.0 +0200
@@ -122,6 +122,8 @@
else
type = Account::H323;
+ limited = (name.find ("%limit") != std::string::npos);
+
registration_event.connect (sigc::mem_fun (this, &Opal::Account::on_registration_event));
}
@@ -274,6 +276,12 @@
}
+bool Opal::Account::is_limited () const
+{
+ return limited;
+}
+
+
bool Opal::Account::is_active () const
{
return active;
diff -ur ekiga-3.2.5.orig/lib/engine/components/opal/opal-account.h ekiga-3.2.5/lib/engine/components/opal/opal-account.h
--- ekiga-3.2.5.orig/lib/engine/components/opal/opal-account.h 2009-07-19 17:40:21.0 +0200
+++ ekiga-3.2.5/lib/engine/components/opal/opal-account.h 2009-07-19 17:51:10.0 +0200
@@ -122,6 +122,8 @@
bool is_enabled () const;
+bool is_limited () const;
+
bool is_active () const;
void remove ();
@@ -145,6 +147,7 @@
bool dead;
bool active;
bool enabled;
+bool limited;
unsigned timeout;
std::string aid;
std::string name;
diff -ur ekiga-3.2.5.orig/lib/engine/components/opal/sip-endpoint.cpp ekiga-3.2.5/lib/engine/components/opal/sip-endpoint.cpp
--- ekiga-3.2.5.orig/lib/engine/components/opal/sip-endpoint.cpp 2009-07-19 17:40:21.0 +0200
+++ ekiga-3.2.5/lib/engine/components/opal/sip-endpoint.cpp 2009-07-19 17:51:10.0 +0200
@@ -82,6 +82,7 @@
account.get_authentication_username (),
account.get_password (),
account.is_enabled (),
+ account.is_limited (),
account.get_timeout ());
} else {
@@ -574,6 +575,7 @@
const std::string auth_username,
const std::string password,
bool is_enabled,
+ bool is_limited,
unsigned timeout)
{
PWaitAndSignal mut(listsMutex);
@@ -592,6 +594,8 @@
SIPRegister::Params params;
params.m_addressOfRecord = aor.str ();
params.m_registrarAddress = host;
+ if (is_limited)
+params.m_contactAddress = "%LIMITED";
params.m_authID = auth_username;
params.m_password = password;
params.m_expire = is_enabled ? timeout : 0;
diff -ur ekiga-3.2.5.orig/lib/engine/components/opal/sip-endpoint.h ekiga-3.2.5/lib/engine/components/opal/sip-endpoint.h
--- ekiga-3.2.5.orig/lib/engine/components/opal/sip-endpoint.h 2009-07-19 17:40:21.0 +0200
+++ ekiga-3.2.5/lib/engine/components/opal/sip-endpoint.h 2009-07-19 17:51:10.0 +0200
@@ -153,6 +153,7 @@
const std::string auth_username,
const std::string password,
bool is_enabled,
+ bool is_limited,
unsigned timeout);
void OnRegistered (const PString & aor,
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Windows 2000: error message freeaddrinfo
Am Mittwoch, den 29.07.2009, 22:29 +0200 schrieb Dominik: > Hello, > > I'm trying to install Ekiga 3.2.5 in Windows 2000. > But it stops immediately with the following error message: > egika.exe - Einsprungpunkt nicht gefunden > Der Prozedureinsprungpunkt "freeaddrinfo" wurde in der DLL "WS2_32.DLL" > nicht gefunden. > > or in English: > The procedure entry point freeaddrinfo could not be located in the > dynamic link library WS2_32.DLL. > > According to > http://msdn.microsoft.com/en-us/library/ms737931%28VS.85%29.aspx this > function (freeaddrinfo) was added in Windows XP SP2. > > For Windows 2000 there are some workarounds necessary. (please see the > msdn page) > > By the way, Ekiga 3.0.2 haven't had this problem. > > regards > Dominik Thanks, somehow your mail got swallowed by ekiga-devel-list. Yes that is our WINVER 0x501 problem when compiling ptlib. I admit that I used a patch which was too agressive to make ptlib compile with mingw. Since yesterday this has been fixed in ptlib in, I hope, a Win2000 compatible way, see http://sourceforge.net/tracker/?func=detail&aid=2822314&group_id=204472&atid=989748 . In my next build I will use the more conservative approach. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Vista terminate problem
Damien Sandras schrieb: Le mercredi 22 juillet 2009 à 23:22 +0200, Michael Rickmann a écrit : Damien Sandras schrieb: Le mercredi 22 juillet 2009 à 19:49 +0200, Michael Rickmann a écrit : I have a Vista notebook available for three days only. As already reported Ekiga has to be killed at shutdown. It seems a pecularity of Vista which can be overcome by several means. if (Vista) 1) Wait at the end of the main thread ca. 5 secs, or 2) do Wait 100 msec, enumerate Ekiga's threads while (num_threads > 1) The second possibility seems cleaner but is more work and will not look nice. What shall I do? Do we have a bt to know why it deadlocks? Most probably Robert can give us a hint in that case... Yes, any deeper knowlege would be helpful here. At the moment I am poking around. So far I found out that it is just a matter of time. If I put a MessageBox which you have to click at the end of the Windows code Ekiga terminates under Vista properly. XP and 7Ultimate do not need that. The overall picture is that Ekiga's main thread exits and ptlib and opal are supposed to clean up their threads. The last one is the ptlib housekeeper thread. I suppose it is extremely difficult to run Ekiga in gdb, hit ctrl-C when it deadlocks and type 'threads apply all bt' ? The difficult part being the Ctrl-C. Every time I tried, it was exiting gdb instead of interrupting the program execution or do you have a tip for that ? Robert will certainly ask for a backtrace. Does the -d4 tell something interesting? (compared to a working version, ie XP). As to the ctrl-C, I got the work around from http://cygwin.com/ml/cygwin/2006-06/msg00361.html working today, unfortunately to late to test on the Vista computer of my daughter, she has left again. What I do: 1) start Ekiga, 2) look up its PID in taskmanager, 3) start gdb from an Msys shell and attach to the PID, 4) in a second Msys run debugbreak.exe PID . The debugbreak which I used you find in http://wwwuser.gwdg.de/~mrickma/ekiga/others/debugbreak.zip . Let me tell what I found out about Ekiga's termination under Vista, first in general, then with a bit more detail. 1) Vista without service pack and without updates: crash on exit 2) Vista without service pack regularly updated: stuck on exit this is the state of my daughters notebook 3) Vista with SP1 but without updates: stuck on exit 4) Vista with SP1 + SP2 is upto date: crash on exit here I found a computer with Vista licence which we use downgraded to XP Only tried under condition 2): you can get a small number of succesive successful terminations by placing into the shutdown code of src/gui/main.cpp either of a) SetProcessPriorityBoost(GetCurrentProcess(), TRUE); i.e. disabling it b) call_core->reference (), possibly delaying shutdown of Ekiga's opal component. If Ekiga was killed or terminated by the b) hack quite frequently a subsequent attempt to register with ekiga.net fails. Now the details! I have preparared an archive at http://wwwuser.gwdg.de/~mrickma/ekiga/vista-bug-logs.tar.gz (email to the list was bounced) with my attempts. ekiga-stderr-not.txt, ekiga-stderr-yes.txt and the try... folders are from a type 2) installation. They are really from a Vista computer and not from XP as the logs say. I am absolutely shure that ptlib's recognition is wrong here because on my daughter's computer I used her account. Dir vistasp2 is from a type 4) installation and xp-crash from my XP-SP2 at home. ekiga-stderr-not.txt, ekiga-stderr-yes.txt show the difference between the standard stuck and the priority changed (hack a)) behaviour of ekiga stable. All the other attempts are free from any hack. As I did not have the debugbreak running at that time I used for the try...s a break in ptlib/msos/win32.cxx, i.e. the C-library cleanup of Ekiga's GnomeMeeting PProcess-inheritance, and got mostly atypical performance. The only attempt which typically got stuck is try3. vistasp2 is from Vista-SP2, it always crashes. xp-crash shows that a similar crash can also be elicited on a usually sane behaving OS, when the break is set before the ptlib housekeeper is deleted. A quick trial with yesterday's HEADS of Ekiga, Opal and Ptlib on type 2) also got stuck. Fair to say that above problems without the ones where I set unnatural break points do not exist under Windows 7 RC. I am a bit puzzled at the moment and hope that the material is sufficient to get some help. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [Win32] Trouble with audio input peripherals
Thierry Simonnet schrieb: Hello, I continue working on win32 version. The last version of ekiga. exe is available at http://www.pateam.org/archive/tmp/ekiga-win32/trunk/ (http://www.pateam.org/archive/tmp/ekiga-win32/trunk/ekiga-setup-3.3.1-git-302_g5d4151a.exe) with the related Makefile. I've done different tests on the same PC to compare 3.0.2 and 3.3.1-git-302 version with a Philips SPC 900NC PC Camera. - With 3.0.2 : I can't have video but can have sound using camera microphone. I also have sound using Realtek HD Audio. -d 4 output is available at http://www.pateam.org/archive/tmp/ekiga-win32/trunk/ekiga-3.0.2-stderr.txt.gz - With 3.3.1-git-302 : I have video with the same camera but I can't activate micro. If I do it, ekiga send multiple error windows (Error while opening audio output device SoundMax HD audio Only silence will be transmitted. The selected audio device was successfully opened but it is impossible to read data from this device. In case it is a pluggable device it may be sufficient to reconnect it. If not, or if it still is not accessible, please check your audio setup. ). -d 4 output is available at http://www.pateam.org/archive/tmp/ekiga-win32/trunk/ekiga-3.3.1-git-302-stderr.txt.gz . Camera microphone activation at 14:22:00.578 then "Media Patch:1520 GMAudioInputManager_ptlib Encountered error while trying to read data". I have the same trouble when using integrated sound card. I've done the same tests using my laptop. Same trouble with SoundMax HD audio. No trouble with video (Logitech quickCam Express). Best regards Eugen Dedu wrote: I suppose your sound card is not supported by alsa or by ptlib?? Could you send the -d 4 output? It should contain more information about the error. Eugen Thierry Simonnet wrote: Hello, I've done more tests using git-302 version : I ve the following message when enabling audio input : - Error while opening audio output device SoundMax HD audio Only silence will be transmitted. The selected audio device was successfully opened but it is impossible to read data from this device. In case it is a pluggable device it may be sufficient to reconnect it. If not, or if it still is not accessible, please check your audio setup. --- It is easier to break and stop ekiga now. No need to hard stop but enable to have some debug info. Best regards Eugen Dedu wrote: Thierry Simonnet wrote: Hello, it is now possible to have a version of Ekiga for windows. I noticed with the last trunk version (this morning) I can't activate any iaudio input. I can call without trouble but only if audio input is on SILENT. I tested it with a camera with mic and with a camera without mic. Ringing peripherals are OK. Message indicates (for any configuration and for any audio codec) that ekiga is able to open peripheral but it is impossible to read it and then only silence will be transmitted. Unfortunately ekiga goes into an infinite loop. I ask myself if it is not my fault, my last three commits on git... I'll check this evening. -- Thierry Simonnet ESIEE-Paris Par respect pour l’environnement, n’imprimez ce mail que si nécessaire ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list Have a look at the second patch in http://mail.gnome.org/archives/ekiga-devel-list/2009-July/msg00071.html it is against stable but perhaps you can get something similar going for git master as well. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Vista terminate problem
Damien Sandras schrieb: I hope that you have really enjoing holidays, Damien. But to keep the others informed, the Vista stuff is really nagging for me. I think that I spotted the reason for the crash under Vista-SP2 in ptlib and filed a bug at https://sourceforge.net/tracker/?func=detail&aid=2832765&group_id=204472&atid=989748 to let Robert know. Remains the Vista stuck on exit. I have made new d logs (attached) wth the SIGTRAP method outlined before but to me they do not tell very much. d6: Opal Garbage and PTLib Housekeeper happily looping along, gdb: we are waiting for something in the Windows kernel. Michael Hi Michael, First of all, thanks for the continuous work. I think your efforts will lead to a more stable Ekiga. After examinating the logs, I think we can first try fixing the crash. We can fix the deadlock after. When I look at try1-segfault and try2-segfault, I can see the crash is similar and happens in PTLIB. I'll ask Robert if he has an idea. It is a part of the code he knows very well. Le jeudi 30 juillet 2009 à 19:46 +0200, Michael Rickmann a écrit : Damien Sandras schrieb: Le mercredi 22 juillet 2009 à 23:22 +0200, Michael Rickmann a écrit : Damien Sandras schrieb: Le mercredi 22 juillet 2009 à 19:49 +0200, Michael Rickmann a écrit : I have a Vista notebook available for three days only. As already ...huge snip vista-stuck-logs1.tar.gz Description: GNU Zip compressed data ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Vista terminate problem
Am Donnerstag, den 30.07.2009, 21:08 +0200 schrieb Damien Sandras: > Hi Michael, > > First of all, thanks for the continuous work. I think your efforts will > lead to a more stable Ekiga. > > After examinating the logs, I think we can first try fixing the crash. > We can fix the deadlock after. > > When I look at try1-segfault and try2-segfault, I can see the crash is > similar and happens in PTLIB. > > I'll ask Robert if he has an idea. It is a part of the code he knows > very well. > > Le jeudi 30 juillet 2009 à 19:46 +0200, Michael Rickmann a écrit : > > Damien Sandras schrieb: > > > Le mercredi 22 juillet 2009 à 23:22 +0200, Michael Rickmann a écrit : > > >> Damien Sandras schrieb: > > >>> Le mercredi 22 juillet 2009 à 19:49 +0200, Michael Rickmann a écrit : > > >>>> I have a Vista notebook available for three days only. As already huge snip > > ptlib housekeeper is deleted. > > > > A quick trial with yesterday's HEADS of Ekiga, Opal and Ptlib on type 2) > > also got stuck. Fair to say that above problems without the ones where I > > set unnatural break points do not exist under Windows 7 RC. > > > > I am a bit puzzled at the moment and hope that the material is > > sufficient to get some help. > > Michael > > > > ___ Just to keep everybody informed. I have made some progress in solving the crash: do not link Ptlib and Opal statically to Ekiga but use dlls ( https://sourceforge.net/tracker/?func=detail&aid=2832775&group_id=204472&atid=989748 ). As to our Vista stuck on exit problem, I spotted the place where it first becomes apparent: when the interface monitor thread is destructed ( https://sourceforge.net/tracker/?func=detail&aid=2835713&group_id=204472&atid=989748 ). So far I have only a work around which uses brute force and should be avoided. Hopefully its not a heap problem. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Windows XP: "wave" volume goes to zero when calling
m...@kabelfunk.de schrieb:
Hi,
I've installed Ekiga 3.2.5 on Windows XP and as far as I see it works
fine, but... :-)
I used the call back service 5...@ekiga.net for my test.
When the incoming coming window pops up the volume for WAVE in the
audio mixer goes to maximum.
After clicking anwer ("abnehmen") the volume of WAVE goes to zero and I
hear nothing.
Doing a 5...@ekiga.net echo test has the same effect: After the
connection is established the volume is zero.
This happens on a reals XP machine as well as in VirtualBox.
regards
Dominik
PS:
I know there is a small speaker button in ekiga where I can raise the
"wave" volume, too.
But the default seems to be zero, is only configurable during a call and
doesn't save the value between restarts.
Yes, it is a real nuisance. I think that Ptlib does not have control
over the volume settings of the Windows Multimedia interface when
opening the device, but Ekiga just relies on it. Attached patch fixes
that. This does not yet allow Win32 Ekiga to restore output volume from
the last run. I work on that using an extra config key.
The zero setting of the volume slider is a third different shortcoming.
Regards
Michael
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp ekiga/lib/engine/audiooutput/audiooutput-core.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-15 06:05:41.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-15 06:06:29.0 +0200
@@ -364,6 +364,10 @@
AudioOutputSettings settings,
AudioOutputManager *manager)
{
+#ifdef WIN32
+ if (ps == primary)
+current_primary_volume = settings.volume;
+#endif
device_opened.emit (*manager, ps, device, settings);
}
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Windows XP: "wave" volume goes to zero when calling
Michael Rickmann schrieb:
m...@kabelfunk.de schrieb:
Hi,
I've installed Ekiga 3.2.5 on Windows XP and as far as I see it works
fine, but... :-)
I used the call back service 5...@ekiga.net for my test.
When the incoming coming window pops up the volume for WAVE in the
audio mixer goes to maximum.
After clicking anwer ("abnehmen") the volume of WAVE goes to zero and I
hear nothing.
Doing a 5...@ekiga.net echo test has the same effect: After the
connection is established the volume is zero.
This happens on a reals XP machine as well as in VirtualBox.
regards
Dominik
PS:
I know there is a small speaker button in ekiga where I can raise the
"wave" volume, too.
But the default seems to be zero, is only configurable during a call and
doesn't save the value between restarts.
Yes, it is a real nuisance. I think that Ptlib does not have control
over the volume settings of the Windows Multimedia interface when
opening the device, but Ekiga just relies on it. Attached patch fixes
that. This does not yet allow Win32 Ekiga to restore output volume from
the last run. I work on that using an extra config key.
The zero setting of the volume slider is a third different shortcoming.
Regards
Michael
Hi Dominik,
I think I fixed all the audio-output volume settings issues for Win32
with attached two patches. ekiga_1outvolume.diff keeps the output volume
across calls, ekiga_2outvolume.diff across Ekiga sessions - the latter
is more intrusive as it introduces a new config key into the database
which for Win32 is in ekiga.conf. I am just uploading new files to my
directory. Could you try
http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.pre6-release.exe.
I have tested it under XP-SP2 and 7RC. Could you tell me if it fixes the
audio for you. For audio input use the general Windows sliders, its a
thing I don't see any pattern yet.
Regards
Michael
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp ekiga/lib/engine/audiooutput/audiooutput-core.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-15 18:44:04.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-15 18:44:57.0 +0200
@@ -364,6 +364,14 @@
AudioOutputSettings settings,
AudioOutputManager *manager)
{
+#ifdef WIN32
+ /* with the next frame the current volume will be updated
+ to the desired one without further notice, signal it in advance */
+ if (ps == primary) {
+current_primary_volume = settings.volume;
+settings.volume = desired_primary_volume;
+ }
+#endif
device_opened.emit (*manager, ps, device, settings);
}
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp ekiga/lib/engine/audiooutput/audiooutput-core.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-15 08:35:36.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-15 08:36:08.0 +0200
@@ -260,6 +260,9 @@
void AudioOutputCore::stop()
{
+#ifdef WIN32
+ audiooutput_core_conf_bridge->save_volume (primary, current_primary_volume);
+#endif
yield = true;
PWaitAndSignal m_pri(core_mutex[primary]);
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-gmconf-bridge.cpp ekiga/lib/engine/audiooutput/audiooutput-gmconf-bridge.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-gmconf-bridge.cpp 2009-08-15 08:34:53.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-gmconf-bridge.cpp 2009-08-15 08:36:16.0 +0200
@@ -52,6 +52,9 @@
property_changed.connect (sigc::mem_fun (this, &AudioOutputCoreConfBridge::on_property_changed));
keys.push_back (AUDIO_DEVICES_KEY "output_device");
+#ifdef WIN32
+ keys.push_back (AUDIO_DEVICES_KEY "output_volume");
+#endif
keys.push_back (SOUND_EVENTS_KEY "output_device");
keys.push_back (SOUND_EVENTS_KEY "busy_tone_sound");
keys.push_back (SOUND_EVENTS_KEY "incoming_call_sound");
@@ -102,6 +105,18 @@
audioinput_core.set_device (primary, device);
}
+#ifdef WIN32
+ if (key == AUDIO_DEVICES_KEY "output_volume") {
+PTRACE(4, "AudioOutputCoreConfBridge\tUpdating volume for primary");
+
+gint volume = gm_conf_entry_get_int (entry);
+if ((volume < 0) || (volume > 100))
+ volume = 0;
+
+audioinput_core.set_volume (primary, volume);
+ }
+#endif
+
if (key == SOUND_EVENTS_KEY "output_device") {
PTRACE(4, "AudioOutputCoreConfBridge\tUpdating device");
@@ -214,3 +229,13 @@
}
}
+#ifdef WIN32
+void AudioOutputCoreConfBridge::save_volume (AudioOutputPS ps, int volume)
+{
+ AudioOutputCore & audioinput_core = (AudioOutputCore &) service;
+
+ if (ps == primary)
+gm_conf_set_int (AUDIO_DEVICES_KEY "output_volume", volume);
+}
+#endif
+
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput
Re: [Ekiga-devel-list] Windows XP: "wave" volume goes to zero when calling
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 5...@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. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Windows XP: "wave" volume goes to zero when calling
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 5...@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: ekigaGMAudioInputManager_ptlibClosing device
Plantronics Headset
13052: Media Patch:372AudioInputCoreFalling back to SILENT
(Ekiga/Ekiga)
inbetween I fiddled around with the local video button
around here the new call is made
14672: Pool:2612GMAudioInputManager_nullOpening 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
5...@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.
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.
Regards
Michael
diff -ur ekiga.orig/lib/engine/audioinput/audioinput-core.cpp
ekiga/lib/engine/audioinput/audioinput-core.cpp
--- ekiga.orig/lib/engine/audioinput/audioinput-core.cpp2009-08-16
14:20:33.0 +0200
+++ ekiga/lib/engine/audioinput/audioinput-core.cpp 2009-08-16
14:22:04.0 +0200
@@ -327,6 +327,8 @@
PTRACE(4, "AudioInputCore\tStarting stream " << channels << "x" <<
samplerate << "/" << bits_per_sample);
+ internal_set_manager(desired_device); /* is left undetermined after
a call */
+
if (preview_config.active || stream_config.active) {
PTRACE(1, "AudioInputCore\tTrying to start stream in wrong state");
}
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp
ekiga/lib/engine/audiooutput/audiooutput-core.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-16
14:25:21.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-16
14:28:21.0 +0200
@@ -248,6 +248,8 @@
return;
}
+ internal_set_manager(primary, desired_primary_device);/* may be left
undetermined after the last call */
+
average_level = 0;
internal_open(primary, channels, samplerate, bits_per_sample);
current_primary_config.active = true;
_
Re: [Ekiga-devel-list] Windows XP: "wave" volume goes to zero when calling
Eugen Dedu schrieb:
Michael Rickmann wrote:
Michael Rickmann schrieb:
m...@kabelfunk.de schrieb:
Hi,
I've installed Ekiga 3.2.5 on Windows XP and as far as I see it works
fine, but... :-)
I used the call back service 5...@ekiga.net for my test.
When the incoming coming window pops up the volume for WAVE in the
audio mixer goes to maximum.
After clicking anwer ("abnehmen") the volume of WAVE goes to zero and I
hear nothing.
Doing a 5...@ekiga.net echo test has the same effect: After the
connection is established the volume is zero.
This happens on a reals XP machine as well as in VirtualBox.
regards
Dominik
PS:
I know there is a small speaker button in ekiga where I can raise the
"wave" volume, too.
But the default seems to be zero, is only configurable during a call
and
doesn't save the value between restarts.
Yes, it is a real nuisance. I think that Ptlib does not have control
over the volume settings of the Windows Multimedia interface when
opening the device, but Ekiga just relies on it. Attached patch fixes
that. This does not yet allow Win32 Ekiga to restore output volume
from the last run. I work on that using an extra config key.
The zero setting of the volume slider is a third different shortcoming.
Regards
Michael
Hi Dominik,
I think I fixed all the audio-output volume settings issues for Win32
with attached two patches. ekiga_1outvolume.diff keeps the output volume
So should this patch be committed (trunk+stable)?
So far I have only tested it under stable because getting Win32 Ekiga
stable stable is my chief concern at the moment. In itself the patch is
harmless as it only tells audiooutput-core and the volume sliders and
... what the situation is. So I would apply it to both.
across calls, ekiga_2outvolume.diff across Ekiga sessions - the latter
is more intrusive as it introduces a new config key into the database
which for Win32 is in ekiga.conf. I am just uploading new files to my
Couldn't the output volume be initialised from Windows default/current
level? Thus we do not need a new config key.
I can confirm what Vanya Gubkin wrote in
http://mail.gnome.org/archives/ekiga-list/2009-August/msg00032.html .
Moreover, I have builds or times when initial audio output is maximal or
minimal. Never it is right. I do not think that we changed something in
priciple when we fixed the device names in
http://git.gnome.org/cgit/ekiga/commit/?id=90b6fe1cbe6ab7cef3e4954d4cae767e65df9b8c
. My conclusion is that as long as we use the PTLIB/WindowsMultimedia
device, initial output volume is not defined (directsound still crashes
Ekiga). Lately, I also have more Ekigas with zero initial output volume.
That is definitely preferable to maximal volume. Once, I had changed
the Windows volume settings for other applications and when I called
5...@ekiga.net afterwards the lady blew my ears - it was an Ekiga with
maximal volume. I am quite concerned with the health aspect of this.
In general I think an application should be able to restore the sound
settings it used including volume. With the PTLIB/WindowsMultimedia
interface Ptlib accesses the "wave" volume which corresponds to Linux
pcm. So we have no control over the mixer.
I agree that introducing a new config key is a major change for an
application. I would not mind to make this a general discussion.
Let me become practical again. I made the patch two days ago, so it is
not well tested. Give me some more time.
Michael
directory. Could you try
http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.pre6-release.exe.
I have tested it under XP-SP2 and 7RC. Could you tell me if it fixes
the audio for you. For audio input use the general Windows sliders,
its a thing I don't see any pattern yet.
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Windows XP: "wave" volume goes to zero when calling
Hi Jarmo, thank you for your detailed bug description Jarmo Pussinen schrieb: Michael Rickmann wrote: 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 5...@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. 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. I tried both of these versions from ekiga to ekiga without ekiga.net. I noticed that the microphone setting does not seem to have any effect to sound volume. I am using USB microphones. With one I never get any effect with the audioinput slider, with the other more expensive one I get an effect but only under Win7 not XP. I guess without really a lot of work we are in god's hands here. Also I noticed from log that some weird path was used for dialtone.wav. 2009/08/18 11:58:27.421 0:16.270 AudioEvent...duler:3040 AEScheduler Checking pending list with 1 elements 2009/08/18 11:58:27.421 0:16.270 AudioEvent...duler:3040 AEScheduler Trying to load dialtone.wav for event ring_tone_sound 2009/08/18 11:58:27.421 0:16.270 AudioEvent...duler:3040 AEScheduler Trying to load /home/mrickma/src/ekiga/ekiga_build-3.2.pre6/dist/Ekiga/share/sounds/ekiga/dialtone.wav for event ring_tone_sound That is a real bug, fortunately an easy one. audiooutput-scheduler.cpp needs to include winpaths.h , as the other code which references DATA_DIR does for Win32. One of the attached patches suffices to fix this. I also checked for the other win32 specific directories, they are ok. Both versions still sometimes do not shutdown correctly, I inlcuded one log, if it helps. That is really a good one, in the weird sense. You must have hit the exit while a call was still active. After line 8160 Ekiga's main thread ends under Wi32. The following OnRelease stuff is the cleanup of your call. But then, - that is the weird thing - in the next ~650 lines the "PTLib Housekeeper" tries to reestablish your registration. I think this is not really Win32 specific. The real experts here should have a look at it. I guess timingwhise it goes right under a well behaving Linux and mostly also under Windows. This bug looks promising though. I think you have hit a key issue here in Ekiga's shutdown, and I may find a trick to make the bug reproducible. I had other problems, but I could not recreate them after I had done cleaner installation (removed old ekiga.conf) and got video working properly. Those additional problems were: microphone setting was set to maximum between calls (but I think it did not work then either) and hang up failed very frequently. jarmo For the rest of what you observed I have to admit that I have seen it as well ..., at some time somewhere, but I had other more urgent things to fix. Thanks again. Regards Michael diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-scheduler.cpp ekiga/lib/engine/audiooutput/audiooutput-scheduler.cpp --- ekiga.orig/lib/engine/audiooutput/audiooutput-scheduler.cpp 2009-08-18 18:02:51.0 +0200 +++ ekiga/lib/engine/audiooutput/audiooutput-scheduler.cpp 2009-08-18 18:03:38.0 +0200 @@ -37,6 +37,9 @@ #include "audiooutput-scheduler.h" #include "audiooutput-core.h" #include "config.h" +#ifdef WIN32 +#include "../platform/winpaths.h" +#endif using namespace Ekiga; diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-scheduler.cpp ekiga/lib/engi
Re: [Ekiga-devel-list] Windows XP: "wave" volume goes to zero when calling
Hi Domink, thanks a lot for stress testing. Dominik schrieb: Hi Michael, as I promised here are the test results: http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.pre6-release.exe I've made 67 echo tests on the WinXP (SP3) laptop. - 52 were OK. - 15 times I hear no voice and the volume slider in ekiga is deactive. http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga-setup-3.2.pre6-release.exe.isitbetter I've made 50 echo tests and all of them were OK! Even when I re-dial very quickly! In addition, I run the echo test in VirtualBox with both exe files: - normal .exe: 6 times OK, 4 times bad - exe.isitbetter: 20 times OK => Overall, the "exe.isitbetter" it's much more stable than before. It solves all the silence problems. regards Dominik PS: In opposite to the normal exe the isitbetter.exe has the initial 100ms mute. But it doesn't matter, IMHO. Dominik schrieb: Hello Michael, Thanks. Unfortunately, I'm on a business trip for the next days and I haven't access to my private desktop or to my wife's laptop. :-) But you can expect my test results next Friday or latest Saturday, I'll promise. regards Dominik Michael Rickmann schrieb: Hi Eugen, hallo Dominik, [... snip] I think that your results show that we will be able to fix the audio mute issue of Win32 Ekiga at the level of audio devices (technically sound channels) and that both, input and output are affected. Fortunately it does not seem to be network related. That really confines things. From the bug fixing point of view we have to make sure, however, that by adding patches we do not compensate for underlying bugs. Meanwhile I think I found one ( http://sourceforge.net/tracker/?func=detail&aid=2841719&group_id=204472&atid=989748 ) in Ptlib which Ekiga uses and which could affect the volume settings of input and output. I uploaded new 3.2.pre6 files to http://wwwuser.gwdg.de/~mrickma/ekiga/ which with respect to the audio muting only contain the Ptlib fix. I will go on holidays the next nine days. Afterwards I will continue to look into this. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 audio issues cleanup
As far as I can see Win32 Ekiga's audio device / file handling need some
changes:
1) After the GetVolume issue has been fixed in Ptlib (
http://sourceforge.net/tracker/?func=detail&aid=2841719&group_id=204472&atid=989748
) Win32 Ekiga can "store" the volume settings of its primary audio
device in the OS's mixer settings similar to the Linux version. Now
"commit d5761aedc38561b0e Keep the output sound volume across calls
2009-08-18 19:19:32" is counterproductive and should be reversed (see
attached ekiga_1outvolume.diff). It was done under the assumption that
Win32 Ekiga would have to store its volume settings in a config key.
2) Dominik's test results in
http://mail.gnome.org/archives/ekiga-devel-list/2009-August/msg00021.html
show that Win32 Ekiga suffers from a threading issue which prevents the
desired primary audio output device to be saved across calls. I think
that this relates to bug
http://bugzilla.gnome.org/show_bug.cgi?id=586531#c6 . Win32 Ekiga really
needs the patch (for reference see attached ekiga_outaudiodev.diff).
3) As Jarmo Pussinen reported Win32 Ekiga is unable to load
dialtone.wav. It uses the wrong DATA_DIR because
lib/engine/audiooutput/audiooutput-scheduler.cpp does not include
lib/platform/winpaths.h. Attached ekiga_win32dirs2.diff fixes that.
Michael
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp ekiga/lib/engine/audiooutput/audiooutput-core.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-21 08:06:31.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-21 08:08:07.0 +0200
@@ -364,13 +364,6 @@
AudioOutputSettings settings,
AudioOutputManager *manager)
{
-#ifdef WIN32
- /* update the current volume to the desired one */
- if (ps == primary) {
-current_primary_volume = settings.volume;
-settings.volume = desired_primary_volume;
- }
-#endif
device_opened.emit (*manager, ps, device, settings);
}
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp
ekiga/lib/engine/audiooutput/audiooutput-core.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-16
14:25:21.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-core.cpp 2009-08-16
14:28:21.0 +0200
@@ -248,6 +248,8 @@
return;
}
+ internal_set_manager(primary, desired_primary_device);/* may be left
undetermined after the last call */
+
average_level = 0;
internal_open(primary, channels, samplerate, bits_per_sample);
current_primary_config.active = true;
diff -ur ekiga.orig/lib/engine/audiooutput/audiooutput-scheduler.cpp ekiga/lib/engine/audiooutput/audiooutput-scheduler.cpp
--- ekiga.orig/lib/engine/audiooutput/audiooutput-scheduler.cpp 2009-08-18 19:46:47.0 +0200
+++ ekiga/lib/engine/audiooutput/audiooutput-scheduler.cpp 2009-08-18 19:47:39.0 +0200
@@ -37,6 +37,9 @@
#include "audiooutput-scheduler.h"
#include "audiooutput-core.h"
#include "config.h"
+#ifdef WIN32
+#include "platform/winpaths.h"
+#endif
using namespace Ekiga;
diff -ur ekiga.orig/lib/engine/audiooutput/Makefile.am ekiga/lib/engine/audiooutput/Makefile.am
--- ekiga.orig/lib/engine/audiooutput/Makefile.am 2009-08-18 19:46:47.0 +0200
+++ ekiga/lib/engine/audiooutput/Makefile.am 2009-08-18 19:48:43.0 +0200
@@ -5,6 +5,7 @@
AM_CXXFLAGS = $(SIGC_CFLAGS) $(GLIB_CFLAGS) $(PTLIB_CFLAGS)
INCLUDES = \
+ -I$(top_srcdir)/lib \
-I$(top_srcdir)/lib/gmconf \
-I$(top_srcdir)/lib/engine/framework \
-I$(top_srcdir)/lib/engine/audiooutput \
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] windows: minor bugs
Hi Dominik, thanks for your report. Dominik schrieb: Hi Michael, two minor bugs: 1. At the end of the installation there is a checkbox "Run Ekiga". But it doesn't start Ekiga. For me it works. Could it be that you had set Ekiga to start hidden, i.e. iconified in one of your previous installations? 2. Right click on the tray icon shows an empty list with two arrows. After scolling down, the normal pop up entries appears. (info, help, exit) Yes, that needs to be improved. I do not see the arrows but immediately get a rather slowly scrolling popup menu. It seems to be a Windows specific shortcoming of GTK+. Google found other people complaining about it. I would recommend attached patch which prevents Win32 Ekiga from calling the gtk_status_icon_position_menu function. So the menu will appear immediately right top of the mouse cursor. For Win32 this is definitely preferable. regards Dominik I just uploaded new "stable" ..3.2.pre6 files to http://wwwuser.gwdg.de/~mrickma/ekiga for everybody to test. They are pretty up to date and contain my latest fixes, also the one which was contained in the previous ...exe.isitbetter to fix remnants of the greyed audio button bugs. Michael diff -ur ekiga.orig/src/gui/statusicon.cpp ekiga/src/gui/statusicon.cpp --- ekiga.orig/src/gui/statusicon.cpp 2009-08-31 14:04:57.0 +0200 +++ ekiga/src/gui/statusicon.cpp 2009-08-31 14:05:17.0 +0200 @@ -246,7 +246,11 @@ gtk_menu_popup (GTK_MENU (popup), NULL, NULL, +#ifdef WIN32 + NULL, NULL, +#else (GtkMenuPositionFunc)gtk_status_icon_position_menu, icon, +#endif button, activate_time); } ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 - Cross compile+ boost
Thierry Simonnet schrieb: Julien Puydt wrote: Julien Puydt a écrit : Thierry Simonnet a écrit : checking whether the Boost::Signals library is available... yes configure: error: Could not link against ! Could you tell me more? He told more in a private email : I'm wondering if it isn't a problem with the m4 macro used to detect boost -- that they haven't been tested for cross-compilation. I'll have to investigate. Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list I made some tests bypassing configure test. I had the same error messages. After quite some time I tried to compile Ekiga master and also have some difficulties with boost. I think moving to boost will improve Ekiga in the long term. Currently it blocks the Win32 port. The libboost pointers are header only but libboost signals require a compiled lib. Without becoming an expert in Boost-Build, cross compiling may result in something not really safe, and because of name mangling differences we can not use one of the MSVC precompiled packages. So I tried to compile a mini-dev under Windows using MinGW: http://wwwuser.gwdg.de/~mrickma/ekiga/others/boost-1.40_mgw44-mini-dev.tar.bz2 . The lib is gcc-4.4.0 compiled, so the debug format of the ..-d.dll and ..-d.dll.a is not compatible with what we currently use - new gcc-mingw32 packages are already in Debian sid. For passing Ekiga's configure libboost signals test extract the archive into BUILDROOT and add --with-boost=$(BUILDROOT) to the confekiga:= portion of the Win32 Makefile. Then configure should print checking for boostlib >= 1.34... yes checking whether the Boost::Signals library is available... yes checking for exit in -lboost_signals-d.dll... yes Next compilation fails for videooutput-manager-dx.cpp. I feel not fit enough to interpret the 67 kB long error log (attached). Certainly the source file is not used for linux and when comparing the code to videooutput-manager-x.cpp the -dx.cpp has a number of nested (boost::bind (boost::bind (... which the -x.cpp does not have. Making them single "(boost::bind ... this, ..." lets compilation proceed. As I am not fit in boost signals I will not provide a patch. Next error occurs while linking ekiga.exe: lstrmiids -lole32 -luuid -loleaut32 -lquartz -ldnsapi -lboost_signals-d.dll /home/mrickma/src/ekiga/win32/lib/libxml2.dll.a -lws2_32 -L/home/mrickma/src/ekiga/win32/lib accounts.o: In function `_ZN17GmAccountsWindow_D1Ev': gui/accounts.cpp:(.text$_ZN5boost6detail12shared_countC1INS_7signals6detail9slot_base6data_tEEEPT_[boost::detail::shared_count::shared_count(boost::signals::detail::slot_base::data_t*)]+0x5d): undefined reference to `boost::throw_exception(std::exception const&)' collect2: ld returned 1 exit status Is there another boost lib which has to be compiled? Michael ekiga-make.log.gz Description: GNU Zip compressed data ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Various crashes (on master)
Julien Puydt schrieb: Julien Puydt a écrit : Julien Puydt a écrit : But as soon as the call ends, ekiga's gui doesn't get updated anymore by gtk+ -- the moving logo still moves though ; and after a while, it crashes. It does so with or without XV. It does so without video. After the call ended, it has the time to say that the call was ended by me before it freezes, then later on crashes. Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list That one happens under Windows too, reliably about 2 sec after a call has been terminated. It seems to occur in boost. Additionally Win32 has a crash when an account is removed, see attached gdb back traces. In general I thought things were worse. Michael master-crashes-050909.tar.gz Description: GNU Zip compressed data ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 - Cross compile+ boost
Julien Puydt schrieb: Michael Rickmann a écrit : Next compilation fails for videooutput-manager-dx.cpp. I feel not fit enough to interpret the 67 kB long error log (attached). Well... C++ templates often lead to worse. Notice that concepts, which were supposed to make it into C++0x, should have helped make error messages more readable. They were supposed, and should have helped. They were rejected... Certainly the source file is not used for linux and when comparing the code to videooutput-manager-x.cpp the -dx.cpp has a number of nested (boost::bind (boost::bind (... which the -x.cpp does not have. Making them single "(boost::bind ... this, ..." lets compilation proceed. As I am not fit in boost signals I will not provide a patch. Oh, yes! I pushed a would-be fix for that ; sorry! Next error occurs while linking ekiga.exe: lstrmiids -lole32 -luuid -loleaut32 -lquartz -ldnsapi -lboost_signals-d.dll /home/mrickma/src/ekiga/win32/lib/libxml2.dll.a -lws2_32 -L/home/mrickma/src/ekiga/win32/lib accounts.o: In function `_ZN17GmAccountsWindow_D1Ev': gui/accounts.cpp:(.text$_ZN5boost6detail12shared_countC1INS_7signals6detail9slot_base6data_tEEEPT_[boost::detail::shared_count::shared_count(boost::signals::detail::slot_base::data_t*)]+0x5d): undefined reference to `boost::throw_exception(std::exception const&)' collect2: ld returned 1 exit status Is there another boost lib which has to be compiled? No. It's a problem where boost thinks we don't compile with exceptions, and hence we have that function to write ourselves. Is it with an up to date master? I thought I had fixed that one :-/ Thanks, Snark Ok I think I got that one working with attached patch which simply adds the -fexceptions flag to the AM_CXXFLAGS in src/Makefile.am as you had done already for the lib Makefile.am. But in general I am not happy with the C++ exceptions. It seems to add considerable overhad to Win32 ekiga. Can't we write a boost::throw_exception function which writes a PTRACE line and then exits and forget about the C++ exceptions? I upgraded my boost mini-dev at http://wwwuser.gwdg.de/~mrickma/ekiga/others/boost-1.40_mgw-mini-dev.tar.bz2 by adding some truly gcc-4.2.1 crosscompiled boost_signals libs, it makes life easier on Debian based MinGW32 installations. As I would like to improve Win32 Ekiga stable for the next release I just uploaded http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga_build-3.3.1-git-356_gd6ff5f8.tgz for anybody to continue Win32 work on Master. Note, the Makefile is unfinished (copy boost by hand, remove sigc), apparently we can't any longer link Ptlib statically, the last Opal version which worked for me today is 23327. Michael diff -ur ekiga.orig/src/Makefile.am ekiga/src/Makefile.am --- ekiga.orig/src/Makefile.am 2009-09-04 09:18:22.0 +0200 +++ ekiga/src/Makefile.am 2009-09-04 09:20:42.0 +0200 @@ -152,7 +152,9 @@ fi \ fi -AM_CXXFLAGS = $(GTK_CFLAGS) $(GLIB_CFLAGS) $(GNOME_CFLAGS) $(DBUS_CFLAGS) $(BONOBO_CFLAGS) $(OPAL_CFLAGS) $(PTLIB_CFLAGS) $(BOOST_CPPFLAGS) $(SIGC_CFLAGS) $(XML_CFLAGS) $(NOTIFY_CFLAGS) +# FIXME: here we add -fexceptions because ptlib&opal put them out and that's a problem for boost... +AM_CXXFLAGS = $(GTK_CFLAGS) $(GLIB_CFLAGS) $(GNOME_CFLAGS) $(DBUS_CFLAGS) $(BONOBO_CFLAGS) $(OPAL_CFLAGS) $(PTLIB_CFLAGS) \ + $(BOOST_CPPFLAGS) $(SIGC_CFLAGS) $(XML_CFLAGS) $(NOTIFY_CFLAGS) -fexceptions AM_LIBS = $(GTK_LIBS) $(GLIB_LIBS) $(GNOME_LIBS) $(DBUS_LIBS) $(BONOBO_LIBS) $(OPAL_LIBS) $(PTLIB_LIBS) $(BOOST_LDFLAGS) $(BOOST_LIBS) $(XML_LIBS) $(NOTIFY_LIBS) ekiga_LDADD = \ ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Various crashes (on master)
Julien Puydt schrieb: Julien Puydt a écrit : Now I only have to understand why we do that... I'm suspecting a problem of boost::shared_ptr in threads, but I can err. Found the problem (and I have a local patch which I'll push soon), and threads weren't the problem. Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list After hacking my way through tonight's changes to Ekiga master I got a Win32 version in which the crash after call termination is fixed which, however, has a crash on exit (only tested under Win7). The latter was definitely not there yesterday. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Registrar compliance
Yesterday Robert checked commit 23341 into Opal stable which allows
Ekiga to deal with registrars which do not allow RFC1918-IPs and which
may possibly help in complex interface situations as reported in
http://bugzilla.gnome.org/show_bug.cgi?id=592012 . To use Opal's
capabilities I have adapted my patch to Ekiga stable (attached) with
which you have to place the string %limit into the account name. For me
it works for a noRFC provider. Regarding the various possibilities of
non-compliant registrars a simple boolean "is_limited" is rather simple
minded. On the other hand have we only one method to deal with these
registrars at the moment. How shall I proceed?
Michael
diff -ur ekiga.orig/lib/engine/components/opal/opal-account.cpp ekiga/lib/engine/components/opal/opal-account.cpp
--- ekiga.orig/lib/engine/components/opal/opal-account.cpp 2009-09-06 12:58:19.0 +0200
+++ ekiga/lib/engine/components/opal/opal-account.cpp 2009-09-06 12:59:10.0 +0200
@@ -122,6 +122,8 @@
else
type = Account::H323;
+ limited = (name.find ("%limit") != std::string::npos);
+
registration_event.connect (sigc::mem_fun (this, &Opal::Account::on_registration_event));
}
@@ -277,6 +279,12 @@
}
+bool Opal::Account::is_limited () const
+{
+ return limited;
+}
+
+
bool Opal::Account::is_active () const
{
return active;
diff -ur ekiga.orig/lib/engine/components/opal/opal-account.h ekiga/lib/engine/components/opal/opal-account.h
--- ekiga.orig/lib/engine/components/opal/opal-account.h 2009-09-06 12:58:19.0 +0200
+++ ekiga/lib/engine/components/opal/opal-account.h 2009-09-06 12:59:10.0 +0200
@@ -122,6 +122,8 @@
bool is_enabled () const;
+bool is_limited () const;
+
bool is_active () const;
void remove ();
@@ -145,6 +147,7 @@
bool dead;
bool active;
bool enabled;
+bool limited;
unsigned timeout;
std::string aid;
std::string name;
diff -ur ekiga.orig/lib/engine/components/opal/sip-endpoint.cpp ekiga/lib/engine/components/opal/sip-endpoint.cpp
--- ekiga.orig/lib/engine/components/opal/sip-endpoint.cpp 2009-09-06 12:58:19.0 +0200
+++ ekiga/lib/engine/components/opal/sip-endpoint.cpp 2009-09-06 13:00:41.0 +0200
@@ -82,6 +82,7 @@
account.get_authentication_username (),
account.get_password (),
account.is_enabled (),
+ account.is_limited (),
account.get_timeout ());
} else {
@@ -555,6 +556,7 @@
const std::string auth_username,
const std::string password,
bool is_enabled,
+ bool is_limited,
unsigned timeout)
{
PString _aor;
@@ -572,6 +574,8 @@
SIPRegister::Params params;
params.m_addressOfRecord = aor.str ();
params.m_registrarAddress = host_;
+ if (is_limited)
+params.m_compatibility = SIPRegister::e_CannotRegisterMultipleContacts;
params.m_authID = auth_username;
params.m_password = password;
params.m_expire = is_enabled ? timeout : 0;
diff -ur ekiga.orig/lib/engine/components/opal/sip-endpoint.h ekiga/lib/engine/components/opal/sip-endpoint.h
--- ekiga.orig/lib/engine/components/opal/sip-endpoint.h 2009-09-06 12:58:19.0 +0200
+++ ekiga/lib/engine/components/opal/sip-endpoint.h 2009-09-06 12:59:10.0 +0200
@@ -153,6 +153,7 @@
const std::string auth_username,
const std::string password,
bool is_enabled,
+ bool is_limited,
unsigned timeout);
void OnRegistered (const PString & aor,
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 Ekiga-3.2.6 available
After more than two weeks of absence I am back and will care a bit more for Ekiga's Win32 port. So first thing to do was to build the new stable release. You find the installers and how to build in http://wwwuser.gwdg.de/~mrickma/ekiga/stable/ . The Win32 version has two issues: 1) ptlib was patched with a workaround to let Ekiga terminate under Vista. This is still a to do for 3.2.7 . 2) The tray icon menu is difficult to close. Dragging a menu item onto the desktop helps. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga-3.2.6 available
Am Mittwoch, den 23.09.2009, 10:00 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > After more than two weeks of absence I am back and will care a bit more > > for Ekiga's Win32 port. So first thing to do was to build the new stable > > release. You find the installers and how to build in > > http://wwwuser.gwdg.de/~mrickma/ekiga/stable/ . > > The Win32 version has two issues: > > 1) ptlib was patched with a workaround to let Ekiga terminate under > >Vista. This is still a to do for 3.2.7 . > > 2) The tray icon menu is difficult to close. Dragging a menu item onto > >the desktop helps. > > Hi Michael, > > Excellent news! > > I updated http://wiki.ekiga.org/index.php/Windows_Users page yesterday, > but now it is already obsolete :o) Could you take care of it (new > 3.2.pre6 link, is 3.0.2 still *the stable* release?)? > Hi Eugen, it seems I should try to edit the Wiki page, but apparently I am too stupid to create an account. For me the Win32 3.2.6 is better than the 3.0.2 was and equally stable. So I would make 3.2.6 the new stable and put 3.0.2 into the Previous Releases. A new 3.2.pre7 will emerge next week adressing the tray icon. I think that gwdg.de has enough bandwidth (mirroring Debian, Ubuntu, Suse, ...), so that we can leave the files there. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga-3.2.6 available
Am Mittwoch, den 23.09.2009, 11:06 +0200 schrieb michel memeteau: > Hello , thanks for this new release , especially appreciated for Win32 > > 2009/9/23 Michael Rickmann :I think that gwdg.de has > enough bandwidth > > (mirroring Debian, Ubuntu, Suse, ...), so that we can leave the files > > there. > > > I downloaded at 80 Ko/s so it's pretty slow. Why not give Mickael a > way to upload his release on ekiga.org ? > > > Well its DFN (Deutsches Forschungsnetz http://www.dfn.de/index.php?id=74989&L=2 ) so I guess its a provider / gateway problem. I just downloaded at 6.0 M/s. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga-3.2.6 available
Am Mittwoch, den 23.09.2009, 09:44 +0200 schrieb Damien Sandras: > Le mercredi 23 septembre 2009 à 09:35 +0200, Michael Rickmann a écrit : > > After more than two weeks of absence I am back and will care a bit more > > for Ekiga's Win32 port. So first thing to do was to build the new stable > > release. You find the installers and how to build in > > http://wwwuser.gwdg.de/~mrickma/ekiga/stable/ . > > Excellent! > > > The Win32 version has two issues: > > 1) ptlib was patched with a workaround to let Ekiga terminate under > >Vista. This is still a to do for 3.2.7 . > > What's the patch ? It is the one from http://sourceforge.net/tracker/?func=detail&aid=2835713&group_id=204472&atid=989748 . A think that Robert is right in his comment that it plasters over a deeper problem. I suspect that Vista's heap manager falls into a self inflicted loop due to previous mishaps which we have caused. In the logs you usually find the system times a thread has used, this also works for XP and Win7, but only rarely under Vista. There seem to be a number of threads which get killed (!!) before Vista gets stuck with the interface monitor thread. > > > 2) The tray icon menu is difficult to close. Dragging a menu item onto > >the desktop helps. > > I don't understand. Well, Windows' system tray seems pretty different from the notification area which you find under linux. Gtk+ does its best to encapsulate that, but it is not perfect. You right click on Ekiga's status icon, a menu scrolls up (ugly, Win32 does not need the positioning function). If you do not wish to select any of the menu items you click around and can not make the menu disappear. The trick is to click on a menu item, leave the button down and drag the cursor out of the menu (see also http://stackoverflow.com/questions/1138891/gtk-statusicon-and-gtk-menu-on-windows ). Another point is that "gtk_window_has_toplevel_focus" seems unreliable for Ekiga under Win32 so the stuff around line 273 in statusicon.cpp does not work. > > However, I have a question. Do you think that version to be stable > enough to be released as stable publicly on ekiga.org ? > -- > _ Damien Sandras I would not call it stable but beta, something like skype 2.1 for Linux. Win32 Ekiga has better audio but a few other glitches (see point 2 above), but it is perfectly usable. Whether to place it publicly on ekiga.org is more a strategic decision. We certainly need more testers. But I might easily become overdemanded by to many complaints. Would it be possible for one of the real Ekiga developers to borrow a Windows computer test Win32 Ekiga and then tell wether it comes close to the Linux Version. If yes, then place the Win32 port publicly. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga-3.2.6 available
(snip) > >> > >> I updated http://wiki.ekiga.org/index.php/Windows_Users page yesterday, > >> but now it is already obsolete :o) Could you take care of it (new > >> 3.2.pre6 link, is 3.0.2 still *the stable* release?)? > >> > > Hi Eugen, > > it seems I should try to edit the Wiki page, but apparently I am too > > stupid to create an account. For me the Win32 3.2.6 is better than the > > No, you're not! It is just we disabled self account creation because of > some bot. Just give me an username and i'll create you one using your email. > (snip) Thanks for your help. I just updated the wiki. It looks ok now and the links are functional. Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga-3.2.6 available
Hi Jarmo, that local video split sounds serious, thank you for reporting. I have never seen seen something like that. I admit that I have not played very much with the resolutions. For my old Phillips ToU Cam Pro which I use mostly I tried only 640x480 and 320x240 and for both resolutions NTSC. I will try to reproduce your error this evening when I have a Windows Computer with Web Cam available. As to your logs, they all look rather similar to me - in the failed one you just did not get any frame from the cam. Let us take ekiga-stderr-local-video-distorted-02.txt to reconstruct what may be significant. 1) line 93: You wanted 640x480 at 30 fps (NTSC). 2) line 2165: Your cam supports 160x120 and 176x144 at 30 fps, higher resolutions at 15 fps and below. 3) line 2227 and below: ptlib decides to take 352x288 at 25 fps using the cam format 20 which is actually 352x288 at 15fps. 4) line 2413 and following: directx video output appears at 352x288. That is what your pictures approx. are. Did you really choose 640x320 and NTSC in Ekiga? The only mismatch which I can detect is that between the 25 and 15 fps. I will have to compare with my logs tonight. Regards Michael Am Donnerstag, den 24.09.2009, 10:39 +0300 schrieb Jarmo Pussinen: > Jarmo Pussinen wrote: > > Hi > > > > Michael Rickmann wrote: > >> After more than two weeks of absence I am back and will care a bit more > >> for Ekiga's Win32 port. So first thing to do was to build the new stable > >> release. You find the installers and how to build in > >> http://wwwuser.gwdg.de/~mrickma/ekiga/stable/ . > > > > Nice work. > > > > But I have now noticed a problem that my local video is now > > always distorted. I was wondering, why it started happen now and > > then I remembered I had changed picture resolution to 640x480. > > Same problem is also in 352x288 resolution, but my earlier resolution > > 320x240 seem to work fine. > > > > The picture is split in different > > parts of the real picture for example: > > - > > | Part of real picture| > > |- > > | Right side | Left | > > | of the pic- | side | > > | ture| of the| > > | | pic- | > > | | ture | > > | | | > > - > > > > > > But the distortions are not always the same but size, position > > and number (2 or 3) varies. > > > > I attached a zip of logs. It includes pictures of the > > distortions. The distortions are the same in PIP mode, > > local view only mode and at the remote end. > > > > I got also a log of a time, when I had to kill ekiga after > > quit and one when my local video failed to start. > > > > One thing about installer the "Will launch ekiga when Windows Starts." > > is not localized. I checked from the code and it seems that there is > > no macro for it in langmacros.nsh, but the string is used as is in > > ekiga.nsi. > > > > > > Regards > > jarmo > > > > > > > > The missing attachment was too big so I put it here: > <http://www.pt-controlnet.fi/ekiga/ekiga-logs-01.zip> > > jarmo > > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
