Re: [Ekiga-devel-list] Unfrozen code?
Julien Puydt wrote: Eugen Dedu a écrit : Julien Puydt wrote: Eugen Dedu a écrit : If you could fix http://bugzilla.gnome.org/show_bug.cgi?id=570008 I have unfortunately no idea what can start a thread on exit :-( Could you check if on your machine the following lines from engine.cpp are executed twice? if (service_core) delete service_core; I committed a simple patch today... does it change the situation? Nope :o( local-roster-bridge: Component to push contacts into the local roster *** glibc detected *** ekiga-snapshot: corrupted double-linked list: 0x0228eb90 *** === Backtrace: = /lib/libc.so.6[0x7f865dc591b8] [...] (sometimes Segmentation fault, sometimes the message above). (let's continue discussion in bugzilla.) -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Latest TRUNK
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 ? Thanks, -- _ 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
Re: [Ekiga-devel-list] Latest TRUNK
On Mon, Feb 23, 2009 at 8:35 PM, Damien Sandras dsand...@seconix.com 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 can probably tomorrow but I actually have a bug report with 3-4 people reporting similar issues on 3.0.2 on Fedora 10 (the update that was pushed to fix the status issue). Peter ___ 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
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... -- 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
Mike Massonnet a écrit : Le Sun, 22 Feb 2009 20:13:44 +0100, Julien Puydt jpu...@free.fr a écrit : 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? Snark I sense a bug in the matr^W^W your mail client :) Well, I asked separately what the status was and got a go-on answer, then looked back a few mails and realized that string freeze wasn't announced as long ago as I remembered. So I ask again, because the changes I have in mind will probably break such a freeze. Snark ___ 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
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. Also, this might explain (yet to be analysed) your problem where a refcount is 11, afterwards 1; the memory is wrongly delete-d when it has refcount=11, and it is allocated again, which sets this field to 1. Not sure... I have the impression you're confusing the lifetime of the object with the lifetime of the gmref_ptr to that object :-/ Finally, I was wondering why is the whole gmref needed, since all the pointers in service_core could be freed at the real end of ekiga, when service_core itself is deleted (in engine_stop() from engine.cpp). Not all objects are directly attached to the main Ekiga::ServiceCore object. gmref_ptr wasn't there from the start because I wanted a tighter control of how memory was handled. It finally prevented sharing some objects conveniently between some components, so gmref_ptr made memory management more automatic (with a cost). Hope that explains some things :-) Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-list] Ekiga 3.02 for Windows: Logitech QuickCam Pro9000 and choosing Default-SIP ?
Nghiep Luu wrote: Damien, Could kindly remove me from the distribution list please? Nghiep(Dan)Luu Please use the Web address below, at the end of that page you can unsubscribe. ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] ekiga timeout - eeebuntu
Le dimanche 22 février 2009 à 17:01 +0300, Fedor vonBock a écrit : hey damien, check it out It is still the same problem : 2009/02/22 16:57:17.330 0:09.279Housekeeper SIPTransaction 4 SUBSCRIBE timeout, making retry 2 2009/02/22 16:57:17.330 0:09.279Housekeeper SIPSending PDU on udp$86.64.162.35:5060if=udp $84.255.188.217:5066 SUBSCRIBE sip:alikhalf...@ekiga.net SIP/2.0 CSeq: 4 SUBSCRIBE Via: SIP/2.0/UDP 84.255.188.217:5066;branch=z9hG4bKa68a7461-56ff-dd11-82c6-0015afe7d424;rport User-Agent: Ekiga/2.0.12 From: sip:alikhalf...@ekiga.net;tag=32817461-56ff-dd11-82c6-0015afe7d424 Call-ID: 861a4b61-56ff-dd11-82c6-0015afe7d...@khalfan-laptop To: sip:alikhalf...@ekiga.net Contact: sip:alikhalf...@84.255.188.217:5066;transport=udp Accept: application/simple-message-summary Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Expires: 3600 Event: message-summary Content-Length: 0 Max-Forwards: 70 2009/02/22 16:57:18.170 0:10.119Housekeeper SIPTransaction 1 REGISTER timeout, making retry 3 2009/02/22 16:57:18.171 0:10.120Housekeeper SIPSending PDU on udp$62.4.81.180:5060if=udp$84.255.188.217:5063 REGISTER sip:eugw.ast.diamondcard.us SIP/2.0 CSeq: 1 REGISTER Via: SIP/2.0/UDP 84.255.188.217:5063;branch=z9hG4bKfc87c260-56ff-dd11-82c6-0015afe7d424;rport User-Agent: Ekiga/2.0.12 From: sip:324...@eugw.ast.diamondcard.us;tag=3e7dc260-56ff-dd11-82c6-0015afe7d424 Call-ID: 0c7a9360-56ff-dd11-82c6-0015afe7d...@khalfan-laptop To: sip:324...@eugw.ast.diamondcard.us Contact: sip:324...@84.255.188.217:5063;transport=udp Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Expires: 3600 Content-Length: 0 Max-Forwards: 70 2009/02/22 16:57:18.462 0:10.411Housekeeper SIPTransaction 2 SUBSCRIBE timeout, making retry 3 2009/02/22 16:57:18.462 0:10.411Housekeeper SIPSending PDU on udp$62.4.81.180:5060if=udp$84.255.188.217:5064 SUBSCRIBE sip:324...@eugw.ast.diamondcard.us SIP/2.0 CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP 84.255.188.217:5064;branch=z9hG4bKfe16f060-56ff-dd11-82c6-0015afe7d424;rport User-Agent: Ekiga/2.0.12 From: sip:324...@eugw.ast.diamondcard.us;tag=620df060-56ff-dd11-82c6-0015afe7d424 Call-ID: cc21c760-56ff-dd11-82c6-0015afe7d...@khalfan-laptop To: sip:324...@eugw.ast.diamondcard.us Contact: sip:324...@84.255.188.217:5064;transport=udp Accept: application/simple-message-summary Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Expires: 3600 Event: message-summary Content-Length: 0 Max-Forwards: 70 2009/02/22 16:57:19.014 0:10.963Housekeeper SIPTransaction 3 REGISTER timeout, making retry 3 2009/02/22 16:57:19.014 0:10.963Housekeeper SIPSending PDU on udp$86.64.162.35:5060if=udp $84.255.188.217:5065 REGISTER sip:ekiga.net SIP/2.0 CSeq: 3 REGISTER Via: SIP/2.0/UDP 84.255.188.217:5065;branch=z9hG4bKbea84361-56ff-dd11-82c6-0015afe7d424;rport User-Agent: Ekiga/2.0.12 From: sip:alikhalf...@ekiga.net;tag=6ca04361-56ff-dd11-82c6-0015afe7d424 Call-ID: 045b1961-56ff-dd11-82c6-0015afe7d...@khalfan-laptop To: sip:alikhalf...@ekiga.net Contact: sip:alikhalf...@84.255.188.217:5065;transport=udp Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Expires: 3600 Content-Length: 0 Max-Forwards: 70 2009/02/22 16:57:19.330 0:11.279Housekeeper SIPTransaction 4 SUBSCRIBE timeout, making retry 3 2009/02/22 16:57:19.330 0:11.279Housekeeper SIPSending PDU on udp$86.64.162.35:5060if=udp $84.255.188.217:5066 SUBSCRIBE sip:alikhalf...@ekiga.net SIP/2.0 CSeq: 4 SUBSCRIBE Via: SIP/2.0/UDP 84.255.188.217:5066;branch=z9hG4bKa68a7461-56ff-dd11-82c6-0015afe7d424;rport User-Agent: Ekiga/2.0.12 From: sip:alikhalf...@ekiga.net;tag=32817461-56ff-dd11-82c6-0015afe7d424 Call-ID: 861a4b61-56ff-dd11-82c6-0015afe7d...@khalfan-laptop To: sip:alikhalf...@ekiga.net Contact: sip:alikhalf...@84.255.188.217:5066;transport=udp Accept: application/simple-message-summary Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Expires: 3600 Event: message-summary Content-Length: 0 Max-Forwards: 70 2009/02/22 16:57:20.662 0:12.611Housekeeper SIPSet state Terminated_Timeout for transaction 1 REGISTER 2009/02/22 16:57:20.966 0:12.915Housekeeper SIPSet state Terminated_Timeout for transaction 2 SUBSCRIBE 2009/02/22 16:57:21.510 0:13.459Housekeeper SIPSet state Terminated_Timeout for transaction 3 REGISTER 2009/02/22 16:57:21.834 0:13.783Housekeeper SIPSet state Terminated_Timeout for transaction 4 SUBSCRIBE ^CKilled On Fri, Feb 20, 2009 at 10:06 AM, Damien Sandras dsand...@seconix.com wrote: Le vendredi 20 février 2009 à 09:47 +0300, Fedor vonBock a écrit :
Re: [Ekiga-list] A comparison ALSA-PULSE
Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1445068800 I interpret delay as the time the calling routine has to sit waiting until there is space enough in the hardware buffer to write. Available reflects the numbers of (bytes? frames? samples?) available in the hw buffer for the sound card? Available_max: isn't this just the size of the hw buffer, in something( bytes? frames? samples?) i. e., the max number of entities which could be buffered? I am not sure I follow, since there are 2 patterns here alsa-pulse-alsa: delay = 0, avail_max=1764 and avail in between alsa direct: delay + avail = 1764, avail_max varies 1764 seems to be the size of the hw buffer. OK, this is haunting me. To get some peace of mind I need to sort this out, at least for myself. From the alsa docs: snd_pcm_status_get_avail_max: Get maximum number of frames available from a PCM status container after last snd_pcm_status http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g3517971b4faf263cf91d146b5a07169d call. snd_pcm_status_get_avail: Number of frames ready to be read/written snd_pcm_status_get_delay: Delay is distance between current application frame position and sound frame position. It's positive and less than buffer size in normal situation, negative on playback underrun and greater than buffer size on capture overrun. --- So: avail is the number of frames the app (opal) can write to alsa. I doubt the other figures are relevant, and they might certainly be hard to define in the emulated alsa interface provided by pulse. Something is strange in the direct logs. Looking at the avail figures, its something like (after an initial phase): 459, 21, 446, 9, 443, 6, 446, 9, 483, 46, 444, 6, ...the pattern is obvious. I interpret it as something is out of phase between the app (opal?) and the alsa layer. Ideal, these figures should be something around 446, 444, 489, 444, ... ( application writes as soon as there is space to write one period). Possibly nothing is written when avail is small, but it's still not as it should be. BTW, the direct logs shows that avail_max don't excceds 1000 frames - it's roughly 800-900. If this is typical, it should be possible to decrease the buffer to 3 periods (1323 frames) without any significant underrun rate. But this is not important now. As for the alsa logs, the xruns are the endpoint when the avail drops in four steps: 1322, 882, 441, 0/xrun. This is almost exactly 3 periods, 2 periods, 1 period, xrun. It looks like the xrun occurs when avail drops to 0 - which is more than strange. Something is broken also here, I presume this is the same problem as in the direct case. It might be an idea to put some timestamps around the debug printouts just to make sure the very presence of them don't disturb the timing. I don't think so, but I once, when working with something similar, remember storing figures in a buffer only written now and then. It was most likely overkill. But just to be sure... I really wish I had more time. But as I see it, these printouts implies something strange in the current alsa handling, and that this propably ought to be sorted out before trying pulse. As usual, that's if I'm right...Isn't there any other alsa people out there? ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE
Alec Leamas wrote: Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1445068800 I attach more output. What you have seen so far was the log when ekiga plays the ring tone (by far the most damaged sound). When running the echo test the setup is different stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 1 rate : 8000 exact rate : 8000 (8000/1) msbits : 16 buffer_size : 800 period_size : 160 period_time : 2 tstamp_mode : NONE period_step : 1 avail_min: 160 period_event : 0 start_threshold : 1 stop_threshold : 800 silence_threshold: 0 silence_size : 0 boundary : 1677721600 And I cannot see any underrun at all. My echo test uses PCMA. It is possible that with a better codec (i.e. higher rate that 8000), we see them again. Don't really know how to test. I would say that the quality of the echo test with or without pulse is the same (but being only 8000 Hz, it is already not perfect and more difficult to judge). All my tests so far have been run in debug, so the speed of ekiga/opal/ptlib is already lower the release. The quality of the ring tone is though more or less the same. I will try to rerun everything in release. I have 2 points 1) Is the following true: ekiga-pulse gives bad audio quality because there are underruns. So, if for some connection there are no underruns (e.g. my echo test) then, the quality is not expected to be lower than alsa-direct, and we should not complain about pulse. 2) If underruns are (the) evil (or at least the biggest problem), then it would be good to print some indication of how close to the underrun we are. Does alsa provide that? Is it already part of my log? I still have not fully understood your comments about the values printed in the log. I need to get familiar with the terminology. And I have not yet checked for overruns when reading from the microphone. Andrea echo.direct.txt.gz Description: GNU Zip compressed data echo.pulse.txt.gz Description: GNU Zip compressed data ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Trunk compile errors
Alec Leamas wrote: I'm running into troubles (below) compiling trunk. Is it just that it's broken, or is it something in my environment? I've tried both 7675 and 7677, same status. So I guess it's something by me. Anyone else with gcc 4.3? --alec ndpoints/sip-endpoint.cpp:1044: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ endpoints/sip-endpoint.cpp:1065: error: no matching function for call to ‘Opal::Sip::EndPoint::GetDefaultRegisteredPartyName()’ /usr/include/opal/sip/sipep.h:704: note: candidates are: virtual SIPURL SIPEndPoint::GetDefaultRegisteredPartyName(const OpalTransport) endpoints/sip-endpoint.cpp:1044: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ endpoints/sip-endpoint.cpp:1065: error: no matching function for call to ‘Opal::Sip::EndPoint::GetDef gui/main.cpp: In function ‘int main(int, char**, char**)’: gui/main.cpp:4628: error: cannot call member function ‘void PProcess::PreInitialise(int, char**, char**)’ without object Latest trunk for ptlib/opal/ekiga compile fine here. gcc 4.3.3. Tried 7681. Do you have trunk for ptlib/opal/ekiga? -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Trunk compile errors
Eugen Dedu wrote: Alec Leamas wrote: I'm running into troubles (below) compiling trunk. Is it just that it's broken, or is it something in my environment? I've tried both 7675 and 7677, same status. So I guess it's something by me. Anyone else with gcc 4.3? --alec ndpoints/sip-endpoint.cpp:1044: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ endpoints/sip-endpoint.cpp:1065: error: no matching function for call to ‘Opal::Sip::EndPoint::GetDefaultRegisteredPartyName()’ /usr/include/opal/sip/sipep.h:704: note: candidates are: virtual SIPURL SIPEndPoint::GetDefaultRegisteredPartyName(const OpalTransport) endpoints/sip-endpoint.cpp:1044: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ endpoints/sip-endpoint.cpp:1065: error: no matching function for call to ‘Opal::Sip::EndPoint::GetDef gui/main.cpp: In function ‘int main(int, char**, char**)’: gui/main.cpp:4628: error: cannot call member function ‘void PProcess::PreInitialise(int, char**, char**)’ without object Latest trunk for ptlib/opal/ekiga compile fine here. gcc 4.3.3. Tried 7681. Do you have trunk for ptlib/opal/ekiga? Yes. But I've been able to build against the official Fedora RPM:s for opal and ptlib There is something lurking around here, but I'm happy for the moment. I'm busy anyway, as you may have noticed ;-) ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Newbie questions
Question #1: Where can I find the FAQ for this maillist? Question #2: Assuming it's not one of the questions answered in the FAQ, what binary should I download for use on OpenSuSE 11.1? The Ekiga web page lists only those for BSD, OpenSolaris, Windows...and the sources, of course. Much thanks in advance... Joshua ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE ( long)
Andrea wrote: Alec Leamas wrote: Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1445068800 I attach more output. What you have seen so far was the log when ekiga plays the ring tone (by far the most damaged sound). When running the echo test the setup is different stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 1 rate : 8000 exact rate : 8000 (8000/1) msbits : 16 buffer_size : 800 period_size : 160 period_time : 2 tstamp_mode : NONE period_step : 1 avail_min: 160 period_event : 0 start_threshold : 1 stop_threshold : 800 silence_threshold: 0 silence_size : 0 boundary : 1677721600 And I cannot see any underrun at all. My echo test uses PCMA. It is possible that with a better codec (i.e. higher rate that 8000), we see them again. Don't really know how to test. I would say that the quality of the echo test with or without pulse is the same (but being only 8000 Hz, it is already not perfect and more difficult to judge). All my tests so far have been run in debug, so the speed of ekiga/opal/ptlib is already lower the release. The quality of the ring tone is though more or less the same. I will try to rerun everything in release. I have 2 points 1) Is the following true: ekiga-pulse gives bad audio quality because there are underruns. So, if for some connection there are no underruns (e.g. my echo test) then, the quality is not expected to be lower than alsa-direct, and we should not complain about pulse. Yes. And, whatever the problems are, I don't really think it's pulse. I think it's a problem how we handle alsa which is just not that visible today. 2) If underruns are (the) evil (or at least the biggest problem), then it would be good to print some indication of how close to the underrun we are. Does alsa provide that? Is it already part of my log? Yes, in the max_avail, see below. But bear in mind that it's not only a question about if underruns happens, it's also a question how they are handled. Actually, a correct working upper layer (opal...) should never allow alsa underruns, it should rebuffer (send previous data) if nothing else is available. It's sounds much better than an actual underrun. I still have not fully understood your comments about the values printed in the log. I need to get familiar with the terminology. And I have not yet checked for overruns when reading from the microphone. Andrea OK, as long you don't feel I occupy your territory, I'll make a try. After some reading my memories are coming back. But don't take what I say for granted, this *is* complicated. And if anyone who really knows alsa could review this, I would be more than happy... First of all: Alsa is basically, in all interfaces, concerned with frames. A frame is what the hardware handles in parallel. So in a mono stream, a frame is the same as a sample. In a stereo stream, a frame is two samples. The sample is S16_LE (signed 16 bit litte endian) i e, two bytes. So a frame is four bytes when sending the sound (stereo) and two bytes when talking as above (one channel, mono). The next entity is a period. A period is (in this context) a chunk of data transferred from user space to the alsa drivers' hw ringbuffer. The ringbuffer is normally an even number of periods. In the case above the period size is 160 frames. Since a frame is a sample ( mono), it's actually 320 bytes. But it's better to stick to frames, that's what alsa is all about. Last we have the hw bufffer. It's actually a ring buffer, where the application stores data, and the driver/interrupt routines fetches it and transfers it to the sound card. The overrun/underrun condtions is really what happens when the two ringbuffer pointers becomes equal, The period size is 160 frames. 1 frame takes 1/8000 seconds = 1000/8000 ms = period time 160/8 ms = 20 ms. The buffer above is actually 800/8 ms = 100 ms. This is quite a large buffer, with added network latency it might be to large. A goal is to keep the overall latency below 150 ms. The avail reflects the number of frames free to write in the hw buffer. When the buffer is full it's 0. When it's empty, it's the buffer size. The normal behaviour is that the application writes a period as soon as avail is = 1 period. Sending routines should somehow (blocking I/O, event-driven) be sure that avail is indeed = 1 period before it writes
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
When looking for quality info (underruns, other errors etc) it's really a question of what opal provides. It's there all errors are handled, and hopefully logged somehow. *If* opal is the lib handling alsa, which is just a guess from my side. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Alec Leamas leamas.a...@gmail.com writes: When looking for quality info (underruns, other errors etc) it's really a question of what opal provides. It's there all errors are handled, and hopefully logged somehow. *If* opal is the lib handling alsa, which is just a guess from my side. Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! Mark ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Mark T.B. Carroll wrote: Alec Leamas leamas.a...@gmail.com writes: When looking for quality info (underruns, other errors etc) it's really a question of what opal provides. It's there all errors are handled, and hopefully logged somehow. *If* opal is the lib handling alsa, which is just a guess from my side. Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! Indeed., grep tells it all. I have no more understanding than that the alsa functions are present there, and nowhere else. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Newbie with questions...
Hi all, First I've been lurking for some time, and going through the wiki, but still have some very basic questions. Please forgive me if the info is posted someplace and I have missed it, and point me to the location where it is documented. I am new to both linux and Ekiga. I have seen many references to editing the gconf file. Where is this file located? And am I correct that the gconf-editor is called from the command line? Based on the threads I've read, I believe the Ekiga config file is where I will find my solutions. Thanks, Gene ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie with questions...
Reed, Gene R[EQ] gene.r...@embarq.com writes: I am new to both linux and Ekiga. I have seen many references to editing the gconf file. Where is this file located? For me it seems to be in ~/.gconf/apps/ekiga/ And am I correct that the gconf-editor is called from the command line? Yes; at least, that's how I do it. In the distribution I use (Debian) it was packaged separately so I had to install it separately. Based on the threads I've read, I believe the Ekiga config file is where I will find my solutions. That's good. (-: Mark ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie with questions...
Reed, Gene R[EQ] wrote: Hi all, First I've been lurking for some time, and going through the wiki, but still have some very basic questions. Please forgive me if the info is posted someplace and I have missed it, and point me to the location where it is documented. I am new to both linux and Ekiga. I have seen many references to editing the gconf file. Where is this file located? And am I correct that the gconf-editor is called from the command line? Based on the threads I've read, I believe the Ekiga config file is where I will find my solutions. What do you want to do? -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie questions
Joshua Tarplin wrote: Question #1: Where can I find the FAQ for this maillist? Maybe http://wiki.ekiga.org? Question #2: Assuming it's not one of the questions answered in the FAQ, what binary should I download for use on OpenSuSE 11.1? The Ekiga web page lists only those for BSD, OpenSolaris, Windows...and the sources, of course. We do not yet have a binary for OpenSUSE. Each distribution builds programs itself; it's not us who build for all distributions (with a few exceptions). Please check in their own repositories. Ask if you do not know how to do it. -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie with questions...
What do you want to do? I want to remove the STUN server from the file. Similar to what Bas did in the thread [Ekiga-list] Problems incoming calls. At this point I cannot even get Ekiga to register with my provider; I expect it is STUN configuration causing the problem. I use Twinkle successfully with the option NAT traversal not needed. I am running OpenSuSE 11.0. Thanks! -Original Message- Reed, Gene R[EQ] wrote: Hi all, First I've been lurking for some time, and going through the wiki, but still have some very basic questions. Please forgive me if the info is posted someplace and I have missed it, and point me to the location where it is documented. I am new to both linux and Ekiga. I have seen many references to editing the gconf file. Where is this file located? And am I correct that the gconf-editor is called from the command line? Based on the threads I've read, I believe the Ekiga config file is where I will find my solutions. What do you want to do? -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Hi, Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! It is PTLib which contains the code to read from alsa. Surely, the ideal is not to go via ALSA, but have ptlib directly talk to pulse. Thus, we need to write a ptlib plugin for pulse audio. We know how ptlib plugins work. There are example plugins for alsa, esd, oss, sunaudio. The big question is writing a plugin for pulse. What is involved in writing code that talks directly to pulse ? Anyone know example code, or of the pulse api docs? Please don't refer me to docs which say just use alsa code. We are using alsa code, and that is why we are having this issue. Derek. Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Newbie questions
Question #2: Assuming it's not one of the questions answered in the FAQ, what binary should I download for use on OpenSuSE 11.1? The Ekiga web page lists only those for BSD, OpenSolaris, Windows...and the sources, of course. We do not yet have a binary for OpenSUSE. Each distribution builds programs itself; it's not us who build for all distributions (with a few exceptions). Please check in their own repositories. Ask if you do not know how to do it. Merci, mon ami! Joshua ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
