Re: [Ekiga-devel-list] Latest TRUNK
Eugen Dedu wrote: Damien Sandras wrote: Le mardi 24 février 2009 à 15:13 +0100, Eugen Dedu a écrit : Damien Sandras wrote: Le mardi 24 février 2009 à 14:18 +0100, Eugen Dedu a écrit : Damien Sandras wrote: Le lundi 23 février 2009 à 22:34 +0100, Eugen Dedu a écrit : Damien Sandras wrote: Hi, Am I the only one to experience audio problems when doing an outgoing call ? The device can't be opened, and I get a popup. Can somebody try with latest TRUNK of OPAL/PTLIB and Ekiga ? I have the same problem with audio in trunk, I thought I am the only one... Actually, it closes the device because it can't write to it. Can you look in the debug output for the exact error message? I get this : Encountered error while trying to write data. Me too: 2009/02/24 14:13:45.934 0:18.338Aggregator:0x15f68950 OpalCon Media stream threads sta rted. 2009/02/24 14:13:45.938 0:18.342 Media Patch:0x11de8950 Alsa Buffer time is 53125 2009/02/24 14:13:45.938 0:18.342 Media Patch:0x11de8950 Alsa Period time is 10625 2009/02/24 14:13:45.939 0:18.343 Media Patch:0x11e29950 Alsa Buffer time is 53125 2009/02/24 14:13:45.939 0:18.343 Media Patch:0x11e29950 Alsa Period time is 10625 2009/02/24 14:13:45.939 0:18.343 Media Patch:0x11e29950 GMAudioOutputManager_ptlib Encountered error while trying to write data 2009/02/24 14:13:45.940 0:18.344 Media Patch:0x11e29950 AudioOutputCore Closing current device 2009/02/24 14:13:45.940 0:18.344 Media Patch:0x11e29950 GMAudioOutputManager_ptlib Closing device[0] Default (PTLIB/ALSA) 2009/02/24 14:13:45.940 0:18.344 Media Patch:0x11e29950 AudioOutputCore Falling back to SILENT (Ekiga/Ekiga) I should try simpleOPAL to see if the problem is in Ekiga or in OPAL. With today's svn, executing simpleopal -I -H iax2:gu...@misery.digium.com/s I hear the voice. (Shouldn't I hear anything?) Try SIP... Do you have the command line and what to expect...? No... Does today's OPAL fix the problem ? trunk or branch? TRUNK, I still have the problem with 2.7.0-beta0 for OPAL and the corresponding PTLIB. It does not work with today's trunks either, just tested. I found: the problem comes from http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=revrevision=22089 -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gmref_ptr
Le mardi 24 février 2009 à 18:26 +0100, Eugen Dedu a écrit :
Julien Puydt wrote:
Eugen Dedu a écrit :
Julien Puydt wrote:
Eugen Dedu a écrit :
In services.cpp, ~ServiceCore executes pop_back(), and this function
calls the destructor of the element
(http://www.cplusplus.com/reference/stl/list/pop_back.html).
However, the refcount of the objects so deleted is not necessarily 0
(you can print their refcount just before deletion), so the
destructor gets called twice (and the second time this might
generate a segmfault).
gmref_ptrFoo isn't the Foo itself. Destroying the gmref_ptrFoo
decreases the refcount of the Foo object -- and this Foo object is
destroyed only when that refcount reaches zero.
Hm... seems you're right.
I receive the segm fault when deleting gtk-frontend because gtk-core
was already destroyed. Now please look at the order of add/delete in
this code from services.cpp:
Ekiga::ServiceCore::~ServiceCore ()
{
/* this frees the memory, if we're the only to hold references,
* and frees the last first -- so there's no problem
*/
while (services.begin () != services.end ()){
services.pop_back ();
}
}
bool
Ekiga::ServiceCore::add (gmref_ptrService service)
{
bool result = false;
if ( !get (service-get_name ())) {
services.push_front (service);
service_added (service);
[...]
Shouldn't be push_front with pop_front, or back with back?
Ah, the comment is a leftover from the pre-gmref_ptr days : now we
shouldn't care in which order they are stored... and probably we should
just do nothing in that destructor ; but we shouldn't do it just now :
I'm not confident about the state of the gui code yet.
If I put services.pop_front(), I do not have a crash anymore.
Also, with .pop_back(), the crash appears at gtk-frontend.cpp,
~GtkFrontend, line
gtk_widget_destroy (addressbook_window);
I supposed it's because gtk-core is already destroyed, isn't true?
Notice that you seem to think it's a memory issue, but the crash looks
like a threading issue (on exit, no less!). :-/
If it is a threading issue, then it should not be 100% reproducible on
my machine. I suspect a memory issue because valgrind also tell about
accessing memory in a freed zone.
I can not reproduce, but it becomes urgent to fix this, as well as the
audio problem. Otherwise, no ekiga 3.2.
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] String freeze
Le mardi 24 février 2009 à 20:26 +0100, Julien Puydt a écrit : Eugen Dedu a écrit : Julien Puydt wrote: Eugen Dedu a écrit : We hope to release ekiga 3.1.1 this Monday. Please note that this release corresponds to String Freeze! (http://live.gnome.org/TwoPointTwentyfive) String freeze... does that mean I can't hack on ekiga right now? You can work on ekiga. But, if I understand correctly, we cannot modify strings (well, we can ask for a string exception, but it's really an exception...) Eh, I want to move code around, so that breaks string freeze. When will I be able to commit more ambitious things ? Once the rest is fixed : no more new code until ancient code is stable. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gmref_ptr
Damien Sandras wrote:
Le mardi 24 février 2009 à 18:26 +0100, Eugen Dedu a écrit :
Julien Puydt wrote:
Eugen Dedu a écrit :
Julien Puydt wrote:
Eugen Dedu a écrit :
In services.cpp, ~ServiceCore executes pop_back(), and this function
calls the destructor of the element
(http://www.cplusplus.com/reference/stl/list/pop_back.html).
However, the refcount of the objects so deleted is not necessarily 0
(you can print their refcount just before deletion), so the
destructor gets called twice (and the second time this might
generate a segmfault).
gmref_ptrFoo isn't the Foo itself. Destroying the gmref_ptrFoo
decreases the refcount of the Foo object -- and this Foo object is
destroyed only when that refcount reaches zero.
Hm... seems you're right.
I receive the segm fault when deleting gtk-frontend because gtk-core
was already destroyed. Now please look at the order of add/delete in
this code from services.cpp:
Ekiga::ServiceCore::~ServiceCore ()
{
/* this frees the memory, if we're the only to hold references,
* and frees the last first -- so there's no problem
*/
while (services.begin () != services.end ()){
services.pop_back ();
}
}
bool
Ekiga::ServiceCore::add (gmref_ptrService service)
{
bool result = false;
if ( !get (service-get_name ())) {
services.push_front (service);
service_added (service);
[...]
Shouldn't be push_front with pop_front, or back with back?
Ah, the comment is a leftover from the pre-gmref_ptr days : now we
shouldn't care in which order they are stored... and probably we should
just do nothing in that destructor ; but we shouldn't do it just now :
I'm not confident about the state of the gui code yet.
If I put services.pop_front(), I do not have a crash anymore.
Also, with .pop_back(), the crash appears at gtk-frontend.cpp,
~GtkFrontend, line
gtk_widget_destroy (addressbook_window);
I supposed it's because gtk-core is already destroyed, isn't true?
Notice that you seem to think it's a memory issue, but the crash looks
like a threading issue (on exit, no less!). :-/
If it is a threading issue, then it should not be 100% reproducible on
my machine. I suspect a memory issue because valgrind also tell about
accessing memory in a freed zone.
I can not reproduce, but it becomes urgent to fix this, as well as the
audio problem. Otherwise, no ekiga 3.2.
I would propose (as RM :o)) that someone :o) review very carefully the
involved changes between 7603 and 7614 to see the problem, or revert
those changes.
--
Eugen
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] please unsubscribe me from this group
___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] please unsubscribe me from this group
wendell wrote: ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list Use the above Web address, at the end of the Web page you can unsubscribe. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Minor patch
To apply, thanks. (if (!...) inside the else is useless)
--
Eugen
--- src/gui/main.cpp 2009-02-11 23:27:42.0 +0100
+++ src/gui/main.cpp2 2009-02-25 15:21:44.0 +0100
@@ -1515,7 +1515,7 @@
if (gm_connect_button_get_connected (GM_CONNECT_BUTTON (mw-priv-connect_button)))
hangup_call_cb (widget, data);
- else if (!gm_connect_button_get_connected (GM_CONNECT_BUTTON (mw-priv-connect_button))) {
+ else {
if (!mw-priv-current_call)
place_call_cb (widget, data);
else
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] String freeze urgent problems
Hi, We are in string freeze. What po files do translators work on? - If they use ekiga 3.1.0 tarball, the strings are not recent (not the last ones). - If they use po files from svn ekiga/po/ directory, these files are not the last ones either, because they have not been regenerated (cd po; make update-po; svn ci) So what's the solution? The best would be to fix the audio bug, do any remaining changes to strings (!!) and release ekiga version. If this cannot be done very fast, then regenerate po files (make update-po; svn ci, as shown above) (I assume that translators use po files from svn, not from last release.) What do you think? Am I wrong somewhere? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] String freeze urgent problems
Le mercredi 25 février 2009 à 17:43 +0100, Eugen Dedu a écrit : Hi, We are in string freeze. What po files do translators work on? - If they use ekiga 3.1.0 tarball, the strings are not recent (not the last ones). - If they use po files from svn ekiga/po/ directory, these files are not the last ones either, because they have not been regenerated (cd po; make update-po; svn ci) They regenerate them themselves. It is not our job, don't worry :-) Damien ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Latest TRUNK
Le mercredi 25 février 2009 à 12:28 +0100, Eugen Dedu a écrit : It does not work with today's trunks either, just tested. I found: the problem comes from http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=revrevision=22089 You are right. It fixes my problem too. I'll see if something can be done in Ekiga itself, if not, I'll let Robert fix it. Damien ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Latest TRUNK
Le mercredi 25 février 2009 à 19:48 +0100, Damien Sandras a écrit : Le mercredi 25 février 2009 à 12:28 +0100, Eugen Dedu a écrit : It does not work with today's trunks either, just tested. I found: the problem comes from http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=revrevision=22089 You are right. It fixes my problem too. I'll see if something can be done in Ekiga itself, if not, I'll let Robert fix it. The problem is that some methods are now called to write data to the soundcard with a size of 0 and of course, it does not work. I have changed a few things in the engine to allow this. Thanks for leading me in the right direction. The bug is now fixed, and it is thanks to you Eugen! -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] News on debian snapshots
Hi all, News on debian snapshots, starting from this night: * ekiga is now built with gstreamer support (Julien Puydt would be grateful if you can test it, even if there are some known problems). * The AVC plugin is not compiled anymore (the package is still there, but will be removed soon). Please tell if you really need it. It seems to me that ptlib needs libraw1394-dev v1, but v1 is not available anymore on debian unstable and very soon in testing either. Here is the error I receive with v2 installed: make[3]: Entering directory `/home/dedu/softs/ekiga/ptlib2/plugins/vidinput_avc' mkdir -p /home/dedu/softs/ekiga/ptlib2/lib_linux_x86_64/device/videoinput g++ -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -fno-exceptions -Wall -DP_64BIT -fPIC -DPIC -DNDEBUG -Os -fPIC -I/home/dedu/softs/ekiga/ptlib2/include \ -L/home/dedu/softs/ekiga/ptlib2/lib_linux_x86_64 \ -I. -shared vidinput_avc.cxx \ -L/home/dedu/softs/ekiga/ptlib2/lib_linux_x86_64 -lraw1394 -ldv -lrom1394 \ -o /home/dedu/softs/ekiga/ptlib2/lib_linux_x86_64/device/videoinput/avc_pwplugin.so vidinput_avc.cxx: In member function ‘virtual PBoolean PVideoInputDevice_1394AVC::Start()’: vidinput_avc.cxx:166: error: ‘raw1394_set_iso_handler’ was not declared in this scope vidinput_avc.cxx: In member function ‘virtual PBoolean PVideoInputDevice_1394AVC::GetFrameDataNoDelay(BYTE*, PINDEX*)’: vidinput_avc.cxx:374: error: ‘raw1394_start_iso_rcv’ was not declared in this scope vidinput_avc.cxx:418: error: ‘raw1394_stop_iso_rcv’ was not declared in this scope make[3]: *** [/home/dedu/softs/ekiga/ptlib2/lib_linux_x86_64/device/videoinput/avc_pwplugin.so] Error 1 make[3]: Leaving directory `/home/dedu/softs/ekiga/ptlib2/plugins/vidinput_avc' make[2]: *** [optshared] Error 2 * dbus support is still disabled as for now. Please tell me if you need it. * gnome-config-tool needs a bit updated. Cheers, -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
