Re: [Ekiga-list] Issues
Hi, We've had this discussion before We have. too many times. For the uninitiated, pulse stands for "painfully useless linux sound engineers" The biggest single issue in linux is sound. yet, we have had apps doing sound for over a decade in linux. What happened to that fast moving, quickly evolving code base the web pages talked about. What happened to that "loosely knit group of developers working together" Nothing. The web pages I quote from, describing the wonders of linux, were wrong. With all the development effort that went into audio, and continues to go into audio, why is sound still a mess - after a decade (or more) of development? === Alsa- the only thing advanced about alsa is in the name. The documentation in this project is atrocious. The usability is bad. Sigh, end of ranting. Derek. On Tue, 5 Jan 2010, Bruce Ferrell wrote: Derek, pulse isn't right anywhere and the only the the pulse devs says is it's the applications fault Which I would say OK to except it's ALL the applications. That answer points to lousy devs who refuse to accept that they've made an error Bruce P.S. We've had this discussion before Derek Smithies wrote: Hi, One of the answers on this topic said that you had to use pasuspender, and make some changes to alsa configuration files. the changes required are non trivial. Some people claim the changes are easy - just paste in these couple of lines they say. Those people were lucky. Other people have invested tens of hours trying to decode & understand the meaning of the components in the alsa configuration files. After too many hours of bitter experience, I suggest that you **Forget pasuspender **Refuse to make any changes to your configuration files. The most recent version of ubuntu (9.10) has made a "reasonable" job of pulseaudio. I suspect that the other major distros (fedorra, suse) have also got pulse right. The main problem in pulse is the *number of misbehaving alsa based applications out there, which do things wrong. *alsa audio drivers not being 100% compliant with alsa spec. I suggest that you upgrade to the latest distro and get the most recent versions of the different drivers. I suggest you shut down every application that makes audio on your desktop. One of them may be killing the sound device. If you do a wireshark dump of the entire call, remember to set the packet size to 2000, and look for the udp packets (which carry the voice). There will be two streams of udp packets. One stream from you to him. One stream from him to you. you said voice stops after 15 (or so) seconds. Do the udp packets stop being sent from your end? if they do, you know that the problem is at your end. Silence detection may have gone wrong. Turn off silence detection. Does this help? Eliminate the possibility of it being a firewall issue. Get a second computer on your lan. Can you do a ekiga call to that computer, and does the voice last longer than 15 seconds? Get the other person to do the same. Derek. === On Tue, 5 Jan 2010, David Bowman wrote: Okay, so first I'd like to say thank you for everything. I'm a little further out of the water but I was wondering what this means: [jetblackbivo...@localhost ~]$ pasuspender ekiga ALSA lib conf.c:976:(parse_value) default is not a string ALSA lib conf.c:1589:(snd_config_load1) _toplevel_:12:9:Unexpected char ALSA lib conf.c:2850:(snd_config_hook_load) /etc/alsa/alsactl.conf may be old or corrupted: consider to remove or fix it ALSA lib conf.c:2714:(snd_config_hooks_call) function snd_config_hook_load returned error: Invalid argument ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:0 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:1 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:0 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:1 Both me and my partner could not be more grateful for all your help. Thanks for your time, David ___ 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 -- Derek Smithies Ph.D. IndraNet Technologies Ltd. ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ "The only thing IE should be used for is to download Fire Fox" "My favorite language is call STAR. It's extremely concise. It has exactly one verb '*', which does exactly what I want at the moment." --Larry Wall ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Issues
Hi, One of the answers on this topic said that you had to use pasuspender, and make some changes to alsa configuration files. the changes required are non trivial. Some people claim the changes are easy - just paste in these couple of lines they say. Those people were lucky. Other people have invested tens of hours trying to decode & understand the meaning of the components in the alsa configuration files. After too many hours of bitter experience, I suggest that you **Forget pasuspender **Refuse to make any changes to your configuration files. The most recent version of ubuntu (9.10) has made a "reasonable" job of pulseaudio. I suspect that the other major distros (fedorra, suse) have also got pulse right. The main problem in pulse is the *number of misbehaving alsa based applications out there, which do things wrong. *alsa audio drivers not being 100% compliant with alsa spec. I suggest that you upgrade to the latest distro and get the most recent versions of the different drivers. I suggest you shut down every application that makes audio on your desktop. One of them may be killing the sound device. If you do a wireshark dump of the entire call, remember to set the packet size to 2000, and look for the udp packets (which carry the voice). There will be two streams of udp packets. One stream from you to him. One stream from him to you. you said voice stops after 15 (or so) seconds. Do the udp packets stop being sent from your end? if they do, you know that the problem is at your end. Silence detection may have gone wrong. Turn off silence detection. Does this help? Eliminate the possibility of it being a firewall issue. Get a second computer on your lan. Can you do a ekiga call to that computer, and does the voice last longer than 15 seconds? Get the other person to do the same. Derek. === On Tue, 5 Jan 2010, David Bowman wrote: Okay, so first I'd like to say thank you for everything. I'm a little further out of the water but I was wondering what this means: [jetblackbivo...@localhost ~]$ pasuspender ekiga ALSA lib conf.c:976:(parse_value) default is not a string ALSA lib conf.c:1589:(snd_config_load1) _toplevel_:12:9:Unexpected char ALSA lib conf.c:2850:(snd_config_hook_load) /etc/alsa/alsactl.conf may be old or corrupted: consider to remove or fix it ALSA lib conf.c:2714:(snd_config_hooks_call) function snd_config_hook_load returned error: Invalid argument ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:0 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:1 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:0 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hw:1 Both me and my partner could not be more grateful for all your help. Thanks for your time, David -- Derek Smithies Ph.D. IndraNet Technologies Ltd. ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ "The only thing IE should be used for is to download Fire Fox" "My favorite language is call STAR. It's extremely concise. It has exactly one verb '*', which does exactly what I want at the moment." --Larry Wall___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Issues
On Wed, 30 Dec 2009, Chris Vine wrote: On Wed, 30 Dec 2009 22:15:55 +1300 (NZDT) Derek Smithies wrote: If the cause of an audio problem is likely to be pulseaudio, what is the user to do? Start it with pasuspender (and make sure that in asound.conf, pulse is not the default server for pcm). Chris, - this is the wrong answer. You are asking the user to: *start ekiga with pasuspender *make sure that pulse is not the default server for pcm in asound.conf For the newbie, this is impossible. This will break most desktops Even for the moderately capable linux person, this is hard to achieve. Surely the correct answer is: improve pulse audio in ptlib. To achieve this, we need to * enter into dialogue with the pulse audio developers. * start taking notice of audio bug reports and consider them as worthy of attention. 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] Issues
Hi, Thanks for the answer, but it leaves me uncertain. On Wed, 23 Dec 2009, Julien Puydt wrote: David Bowman a écrit : The problem is that in the middle of calls to my partner he stops being able to hear me. Pulseaudio. If the cause of an audio problem is likely to be pulseaudio, what is the user to do? Pulse audio is standard on all the major linux distros. Doing a complete removal of pulseaudio from my ubuntu 9.10 box will cause the entire ubuntu-desktop to be removed, breaking quite a few apps. So - what are we asking users to do? remove pulseaudio ? surely not. write a new set of entries to their asound.conf? a task only for the knowledgeable. switch to debian (or gentoo or.. ) and use alsa, not pulseaudio? some linux users are experienced enough to achieve this. There is a pulseaudio plugin in the ptlib SVN repository. Has the latest version of this been tested? If pulseaudio is faulty - then we should be passing developer feedback to the pulse community, and they fix it. if the pulseaudio plugin in the ptlib SVN repository is faulty - then we fix it. So far, the reported bugs in that plugin have been fixed. We cannot tell people to use alsa. We have to make pulseaudio work with Ekiga. = Every now and then I read that someone says, "linux is ready for the desktop". Fools. the setup of sound on linux is so hard and convoluted that linux is not ready for the desktop. If you think that sound on linux is ok, try the following test. Plug a usb headset into your computer. start watching a youtube video, or flash animation. change a gui control to send sound to your headset. To achieve the above, if you had to write extra lines to your asound.conf file, or modify the order of sound modules on your box with module parameters, well, you showed that linux sound is hard&complicated, and not ready for the newbie. 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] openal, virtual box...
Hi, I've a sound problem, the microphone is stoped when starting an application using OpenAL, or when launching a virtualbox within sound support. yep. The classic sound problem of linux. My guess as to what is happening:: When you start an application that uses openal, it takes exclusive ownership of the sound card. Consequently, no other application on the box can access the microphone side of that sound card. Now, Ekiga cannot access the microphone. Sadness. The problem is that one application on a box should not be able to grab exclusive acccess to the sound card, and lock all other applications out from the sound card. Imagine this happening to your desktop apps. Your mail tool could make a beep with incoming messages, but your IM client could not make a beep for events. Over the years, there have been various attempts to solve this problem. You have artsd - which had serious flaws. You have the alsa type approach, of putting lots of sound cards in the box. let the system have sound card 0, and Ekiga uses sound card 1. This actually works quite well. When this approach is used with OSS, the result is perfect... You then have cleverer cards/drivers, which let multiple applications access the sound card at the same time, provided they use the same sample rate. Now, ptlib&opal are based on 8khz, which is a bit lower than the desktop rate of 48khz.. I think that Ekiga and your openal app are having a problem as they are trying to access the microphone at different rates. yes, Ekiga can up/down sample the rates to 48khz. At the cost of cpu time. If it is a USB headset/mic, well, will the usb connection cope with the data, and the latency requirements?? Pulse was invented as a sound server that would allow all applications to access any sound device at any rate. Pulse is the main approach on ubuntu. With pulse, there are problems.. High latency. High cpu requirements. The control guis are ugly. The control guis are not reliable, intuitive or even sensible. I am forced to conclude that pulse stands for "patheticly useless linux sound engineers" Derek. On Sat, 19 Sep 2009, Frederic Scherma wrote: Hello, Firstly, thanks for our work on this useful software. I've a sound problem, the microphone is stoped when starting an application using OpenAL, or when launching a virtualbox within sound support. Ekiga 3.2.5 OpenAL 1.1 Alsa 1.0.21 Debian SID 2.6.30-1-amd64 Sound card SB Audigy 2 ZS KDE 4.3.1, no pulseaudio, no jackaudio, only artsd, xine, and gstreamer Regards, Frédéric ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- 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] Ekiga support G.729(a)?
Hi, On Sun, 16 Aug 2009, yannick wrote: LiQun Li a écrit : Hi, all, I am using Ekiga 3.2, I can find g.729(a) codec. How can I get Ekiga support g.729(a)? or I have to wait? G.729 is patented, we cannot use it in a free software project. http://www.sipro.com/g729_faq.php Really? ippcodecs from sourceforge provides a g729 for linux. http://sourceforge.net/projects/ippcodecs/ you can use these codecs - there are some issues with them in a commercial situation, but for home use, 1 channel, they are fine. the ippcodecs are a bit heavy on cpu.. 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] Alsa device enumeration
Hi, On Thu, 12 Mar 2009, Damien Sandras wrote: I'm not sure. How can we know surround is non sense? How can we know other similar non sense entries... To my eyes, Alsa is really purely broken :-/ Very broken. Alsa stands for advanced linux sound architecture - which is misleading. Alsa rhymes with, and sounds very much like, the word "ulcer". = Sound cards - my colleagues and I did a count of the typical number. On a PC prior to 2000, (or so) the motherboard had a deficient onboard sound system, and you had to install a proper sound card. On the more recent PCs, (and laptops) the onboard sound is fine. However, the user will plugin in USB headsets (which are represented by alsa) as a sound card. Thus, we have to consider a PC as containing 2 sound cards: 1 that is always there 1 that comes and goes while the application is running. = The labelling is deficient. I have a machine here that has two sound cards. 1 on the motherboard, 3x3.5mm sockets, mic, speaker, line in (yes, 3 sockets.. only one is output) 1 ES1371 (ensoniq) 4x3.5mm sockets, mic, speker, linein, lineout Ok, now remember this description of 7x3.5mm sockets. How does alsa report this as ? output of aplay -l List of PLAYBACK Hardware Devices card 0: AudioPCI [Ensoniq AudioPCI], device 0: ES1371/1 [ES1371 DAC2/ADC] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: AudioPCI [Ensoniq AudioPCI], device 1: ES1371/2 [ES1371 DAC1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: AudioPCI_1 [Ensoniq AudioPCI], device 0: ES1371/1 [ES1371 DAC2/ADC] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: AudioPCI_1 [Ensoniq AudioPCI], device 1: ES1371/2 [ES1371 DAC1] Subdevices: 1/1 Subdevice #0: subdevice #0 output of aplay -L front:CARD=AudioPCI,DEV=0 Ensoniq AudioPCI, ES1371 DAC2/ADC Front speakers surround40:CARD=AudioPCI,DEV=0 Ensoniq AudioPCI, ES1371 DAC2/ADC 4.0 Surround output to Front and Rear speakers iec958:CARD=AudioPCI,DEV=0 Ensoniq AudioPCI, ES1371 DAC2/ADC IEC958 (S/PDIF) Digital Audio Output null Discard all samples (playback) or generate zero samples (capture) front:CARD=AudioPCI_1,DEV=0 Ensoniq AudioPCI, ES1371 DAC2/ADC Front speakers surround40:CARD=AudioPCI_1,DEV=0 Ensoniq AudioPCI, ES1371 DAC2/ADC 4.0 Surround output to Front and Rear speakers iec958:CARD=AudioPCI_1,DEV=0 Ensoniq AudioPCI, ES1371 DAC2/ADC IEC958 (S/PDIF) Digital Audio Output = Here is the problem: we need to turn the above two lists into something meaningful for the user. both cards on this machine are reported as having two play subdevices. Yet only one is available. Which card is which? Which card is the motherboard, and which card is in the PCI socket? One of the tasks of the alsa code has to be to work out what the physical location of each card is, and report it accordingly. Now, this is just one example of the brokenness of alsa. Every application that uses alsa has to enumerate sound cards, work out their physical location, work out when new cards (usb headsets etc) are plugged in... Isn't that what libraries are for - so that common code goes in the library, and applications share the output of the common code??? 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] PTLIB alsa plugin status
On Sat, 28 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 It is set in opal in OpalAudioMediaStream::OpalAudioMediaStream( where soundChannelBuffers is set to the supplied parameter value. This comes out of the pcssendpoint class, which which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth... soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() so you know what ? I think this is a bug from outside of ptlib&opal. The default values for codec sizes in ptlib&opal are for a count of 2 buffers (unix) and 3 buffers(windows). Derek. which verifies Andreas' logs i. e., this is what causes the oversized alsa hw buffer. I made a quick search, there are no references to SetBuffers in the plugin code. So these calls comes from the upper layers. For the moment I'll stick to the alsa plugin and will not investigate this any further. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- 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] PTLIB alsa plugin status
Hi, On Sat, 28 Feb 2009, Alec Leamas wrote: Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) No offense taken. I put that comment in to lighten the tone a little. After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: yeah - it is much easier to avoid such battles and put in cerr statements... These battles are a pain and a complete waste of time. They really really annoy me. Like, autoconf was supposed to remove hassle. It hasn't. The kernel does not use autoconf -- which suggests to me that autoconf is not all capable. The ptlib&opal build system consists of multiple projects that interdepend on each other. autoconf (ideally) requires us to duplicate code and directories, and separate the projects out. forget that. Derek. > Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 which verifies Andreas' logs i. e., this is what causes the oversized alsa hw buffer. I made a quick search, there are no references to SetBuffers in the plugin code. So these calls comes from the upper layers. For the moment I'll stick to the alsa plugin and will not investigate this any further. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- 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] PTLIB alsa plugin status
Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) Later on, I'll try refine the documentation for PsoundChannel. cool. Email any docs you have to me directly, and I will add them to the inline documentation in the ptlib sources. 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] PTLIB alsa plugin status
On Fri, 27 Feb 2009, yannick wrote: I've no clue if this documentation might help, still the pulse audio main author refers it as "a guide": http://0pointer.de/blog/projects/guide-to-sound-apis.html Especially the section "You want to know more about the safe ALSA subset?" This is a great link. There are some non optimal components in the alsa plugin, or rather, things that are not "safe". I have some sadness at this - the alsa plugin in ptlib was "copied" from the example they provided. 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] PTLIB alsa plugin status
Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: Hm... a write operation could be guaranteed to return in finite time (using non-blocking io + snd_pcm_wait). So couldn't the close method just mark the chanell as closing, leaving the dirty work to the "writer" thread and thus avoiding the locks? (Which, otoh, really isn't a big issue in this scenario). If required, opening could be handled in the same way, I guess. This would also create the advantage that the thread could process the jitter buffer data in parallel with the alsa output, without the need to wait for the IO to complete. Wouldn't this give a more accurate timing? Also, avoiding blocking io is a Good Thing IMHO. No. It must be a blocking write. The architecture of opal demands this. The play thread (using play as an example) repeatedly does the following read rtp packet from jitter buffer decode put raw audio to sound device (which delays for up to framesize of packet) There was a time when pwlib and openh323 (the old names of ptlib and opal) used non blocking writes to the sound card plus software timers. the software timers were found to not be reliable enough to delay the write thread. Sometimes the delay was hundreds of milliseconds. So openh323 and pwlib were changed to use blocking writes, which gave much better audio performance. to change the operation of the write to be non blocking would have major architectural implications to opal. Let me help you. This won't happen. I don't think this aspect of the the Opal design is a problem. The problem we are are trying to address is the reason for the buffering - why is there a 100ms delay??? Yes. I *think* I've seen five periods hardcoded somewhere... Can you find the hardcoded bit? And report it? Answer: There are two entities that I have seen which can "store" audio to give you a delay. The jitter buffer, which can store seconds of audio. There are status variables in the jitter buffer which indicate how long it is buffering audio for. As I suspected. Thanks also for this. So basically we have network latency, jitter/echo cancellation buffer and the device/alsa buffer, all in total preferably in the 150 - 200 ms range. If there is no echo cancellation, the alsa buffer (if larger) could also be jitter buffer. But not if fancy things like echo cancellation should be performed (?). You may have the answer here. How much delay does the speex echo cancellor introduce ? it is defaulted to.. The thing is that when looking at the alsa device from the operating system level (in the /proc filesystem) it's clear that the buffer is 5 periods * 20 ms = 100 ms (details in the thread initiated by Andrea). So something is not as expected... Is the simple truth that the alsa period size doesn't match the codec chunk size? But even if so, should it matter? "suspicious" Alsa probably introduces a delay/buffering of its own when you do alsa<-->pulse conversions. Can you repeat the above test on an older distro where the machine does not have pulse? 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] PTLIB alsa plugin status
Hi, On Thu, 26 Feb 2009, Alec Leamas wrote: Just to sort his out, trying to understand the overall requirements. Which is a very reasonable thing to do, and it is a good question. And with the idea that using threads is perfectly reasonable in this context :-) Excellent. This idea is very reasonable. -Let's focus on the playback case, leaving any read aside (which refer to a different alsa device). Good idea. - This should mean that while one thread (A) is closing it's playback device, another thread (B) starts writing to it. Yes, thread B is writing audio to the playback device. Thread B is collecting the data off the jitter buffer, decoding the audio using the specified codec, sending the data to the playback device. thread B is stopped by a bad write to the playback device. Typically, a bad write to the playback device is caused by the playback device being closed. In the gui thread, user clicked hangup, and a close down thread is created. This close down thread runs independantly of the gui (so does not hold up the gui so responses work ok) and makes a call to OpalCall::Clear() (which is a structure inside Opal) which then goes through all the RTP threads (including audio) and closes the devices. Since the Open, Close and Read/Write operations are atomic, there is no possibility of one happening while the other happens and breaking things. The Opal thread which does the call to device Open then goes on to launch the read/write threads. So read/writes don't run before the device is open. I don't think this aspect of the the Opal design is a problem. The problem we are are trying to address is the reason for the buffering - why is there a 100ms delay??? Answer: There are two entities that I have seen which can "store" audio to give you a delay. The jitter buffer, which can store seconds of audio. There are status variables in the jitter buffer which indicate how long it is buffering audio for. The sound device. Opal sets the sound device (on linux) to store 2 buffers of audio, which is (at most) 2 x 30ms. One of the 30ms buffers is the buffer currently being written to the sound device. The second 30ms buffer is the next buffer to be written. The buffering depth is set by the call to devices/audiodev.cpp:bool PSoundChannel_EKIGA::SetBuffers (PINDEX size, PINDEX count) size is <=480 (480 is for a 30ms long buffer. GSM uses 20ms.) count is typically 2 (windows uses 3 or more) It "is" possible that this call is not happening at the right time. I doubt this, but you could verify this with a review of the logs. If this command was being missed, the sound device would get whatever value it is defaulted to.. 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] PTLIB alsa plugin status
On Thu, 26 Feb 2009, Alec Leamas wrote: But there *are* problems. A well behaved alsa driver should work better aganist pulse, other does. The hw buffer is way to large, 100 ms latency instead of ~50. No statistics. No rebuffering. But you have convinced on one, important point: it should be possible to enhance the driver with a set of smaller patches instead of a major rewrite. Such things are always easier. And I have absolutely no intention to look under the hood in the opal framwork. I just found Andreas' posting, and realized that I had some odd experience in alsa which might be useful. And after looking into this, I still feel that a better alsa interface in Ekiga is really important to get better latency and quality, both of which are crucial in a voip context. Or? BTW, are you the one which have an overall understanding the complete buffering scheme in Ekiga? I understand the ptlib and opal side of things quite well. I had a look at Ekiga, and read about the classes AudioInputCore and AudioInputManager. These Audio classes are necessary to deal with sound device insertion/deletion - such as inserting a USB headset. My first thought was that the OS (not the app) should deal with device insertion/deletion, but Alsa does not. Pulse is supposed to deal with sound device insertion/deletion. The ubuntu forums are full of people complaining about pulse. There is no buffering mechanism in Ekiga that I saw. 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] PTLIB alsa plugin status
Hi, On Wed, 25 Feb 2009, Alec Leamas wrote: Hi :-) Thanks for this info! As you state, this should work as long as they are instantiated in a proper way. And it's simple just to add some assertions to make sure that this is indeed the case. I still don't get why the device pointers needs locking. Is the overall Ekiga design such as there are several threads writing concurrently? Or is this a general requirement for the driver, for other scenarios the Ekiga? In other words , is the PTlib alsa driver defined as reentrant? yes, the ptlib alsa driver needs to be reentrant. One thread could attempt to close the audio device while a second thread is reading/writing data from/to the alsa system. It is not the overall Ekiga design that sets the requirment for coping with multiple threads - it is a the PTLib/OPAL design that sets the requirement for coping with multiple threads. The discussion topic of threads and too many threads and so on has occuppied many hours at conferences, and many emails, and is slightly tedious. A useful article on threads is found at: http://www.gotw.ca/publications/concurrency-ddj.htm In my view, the reason many programmers argue vehemently against threads is a combination of several factors *all their early programs were single threaded (e.g. hello_world) and so they developed the mindset of only knowing how to cope with 1 thread. *some programming styles (which are spaghetti like in nature) are torture to debug when threaded *many of the open source tools (in particular debuggers) don't handle threads well and make the whole code&fix process too hard However, ptlib and opal are coded to a high degree of quality. There are still issues (device plugins) but these are getting fewer and fewer. Given the nature of voip and how voip works, I don't think any other model would work. Remember that opal is a library, and is used by people making hundreds of simultaneous calls. If you do propose a different way of doing things, will the new architecture cope with being scaled up? 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] PTLIB alsa plugin status
Hi, >>> - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? This mutex is important, and should not syncrhonize the play&record threads. There are two PSoundChannel class instances active during a call. One for play. One for record. These PSoundChannel class instances are seperate, and have seperately opened connections to the sound_alsa plugin. Consequently, the mutex you refer to is not syncrhonising access to play&record. The mutex is locking access to play variables (device pointers) + play A different mutex instance is locking access to write variables (device pointers) + write. == Now, if the same PSoundChannel instance is used for play and record - (which can be achieved by bad application writing) then you have an application coding problem. I assume Ekiga does not have this issue. = to blame anyone or so, but I think we must face the fact that there *are* problems, some of them requiring more than a point fix. Agreed. Derek. On Tue, 24 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, Hi :-) Have you checked the bugzilla bug? There's some more meat on the bones (or however you prefer to say it down there ;-) On Tue, 24 Feb 2009, Alec Leamas wrote: - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? It's not just a question of testing. This kind of problem must be handled by careful reading of code, to test all conditions possible when there are concurrent threads is not that simple. I think what should be done is to separate the recording and playback threads into separate objects, thus letting the compiler check that there are no critical zones. I also think the whole idea of a single "channel" must be interpreted as a facade for two more or less independent streams . They should not really share any data. But of course they share a lot of behaviour. - There is no rebuffering support. This means data underruns sounds worse than necessary. What is required to do rebuffering? Any code suggestions? Well, the basic thing is a separate thread feeding alsa started when alsa is started. The write routine just drops it's buffer to the thread through some kind of thread-safe mechanism, being blocked if there is no space in (a small) buffer. The thread is just waiting for alsa (snd:_pcm_wait). When started it normally transfers data from upstream (write), rebuffering as necessary if there is nothing else to send. In my opinion, it's not really worth to put much work on using the current alsa plugin. As long as it works, don't touch it... until it get's fixed in a proper way, possibly by using a pulse plugin instead. It is worth it. Alsa will be around for a long time. This is an opportunity for Ekiga people to contribute back to ptlib&opal (libraries that are crucial to this project) OK, unless you provoke you don't get an answer... I actually share your opinion :-) As for the latency discussion about alsa vs pulse: This review shows that anything will be much better than current alsa code... The current alsa code works mostly.. it is close.. If there was some usable docs at alsa to explain what is not good, that would help. Anyone able to work out what is actually wrong in the alsa plugin? But we have 100 ms of hw buffer, roughly twice the size of other VOIP applications. There are open issues about the overall design, threads, objects etc. There are no quality metrics, we have no idea about things like bytes transferred, hard errors, soft errors, buffer usage etc. And Andreas' logs shows that the driver does not deliver data as expected. I don't want to blame anyone or so, but I think we must face the fact that there *are* problems, some of them requiring more than a point fix. As I said, take a look at the bug, there are some more details, despite the horrible formatting. And bear in mind that I'm certainly wrong from time to time. And that English isn't my native language, the nuances are a bit bit, well, rough now and then :-) Derek. --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- 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] PTLIB alsa plugin status
Hi, On Tue, 24 Feb 2009, Alec Leamas wrote: - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? - There is no rebuffering support. This means data underruns sounds worse than necessary. What is required to do rebuffering? Any code suggestions? In my opinion, it's not really worth to put much work on using the current alsa plugin. As long as it works, don't touch it... until it get's fixed in a proper way, possibly by using a pulse plugin instead. It is worth it. Alsa will be around for a long time. This is an opportunity for Ekiga people to contribute back to ptlib&opal (libraries that are crucial to this project) As for the latency discussion about alsa vs pulse: This review shows that anything will be much better than current alsa code... The current alsa code works mostly.. it is close.. If there was some usable docs at alsa to explain what is not good, that would help. Anyone able to work out what is actually wrong in the alsa plugin? 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] A comparison ALSA-PULSE (long, addendum)
On Tue, 24 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: 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. I think you are right. For the reasons you mention, but also because the current alsa plugin is seriously flawed I made a short review very late yesterday. Among other things it's synchronized in a way that forces playback and record to wait for each others' I/O operations(!) Yes - I am aware of this mutex. Have you tried it with this synchronizing mutex removed? That mutex has been there since the the plugin was written. With this said, I don't (yet) see any problems in understanding and using the external interface. These problems are within the alsa plugin. So: with limited resources we have a choice to either "fix" (i. e., major rewrite of) current alsa plugin, or make a pulse plugin. What is there to rewrite? There are only a few things that are possibly wrong - the synchronising mutex and what else? It is, as you say, copied from the alsa example docs The latter is most likely easier. Not really... But then we leave platforms without pulse in the dark ages. So question is: do we need a working alsa plugin if we have a pulse one? Anyone? (let's take silence as a "no" :-) ) A working alsa plugin is a requirement. There may only be 5 % of users using alsa, but they will scream loud and long if it does not work for them. Some x11 window environments don't have pulse audio in them. So you need pulse and alsa plugins. What disturbs me a little is the way the plugin interface "seems" to be, at least from the alsa example. Question is if there is a way to arrange event-driven I/O - current code is strictly polled. The current code is arranged so that *the application writes/reads a block of data to/from the sound device. *this process is timed by the sound device so that the write/read takes as long as the framesize of the codec. Thus, for GSM (20ms frame) the write/read takes 20ms. It is the sound device that times the sending of UDP packets to the remote endpoint. Software timers are very unreliable (in comparison to hardware timers, where the board/driver determines the read time as being "exactly" 20ms) Suppose we have 3 GSM frames in each UDP packet. This means that every 60ms (silence detection disabled) a UDP packet is sent to the remote node. To do the timing, there is a read of 320 bytes, which takes 20ms, encode of audio frame read of 320 bytes, which takes 20ms, encode of audio frame read of 320 bytes, which takes 20ms, encode of audio frame and the three encoded audio frames are placed in a UDP packet which is sent to the remote host. OTOH, we can live with that, for sure. But there "might* be other hooks in the plugin interface not used today... we might need to backwards-engineer some docs... possibly expanding the plugin interface in a backwards-compatible way Sounds pretty hard way to do things.. I think the PTlib developers won't be happy with expansion of the plugin interface.. There is good pulse doc's on their website e. g., http://0pointer.de/lennart/projects/pulseaudio/doxygen/ Thanks for this. It is a more useful set of documentation than when I last looked for pulse-doc like things. -- 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] 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] Yet an other post on Pulseaudio
Hi, there is a fascinating read on http://glyph.twistedmatrix.com/2009/01/dark-art-of-sound-on-linux.html about sound in linux. He is not overly critical of Ekiga - I get the feeling that he is implying that the Ekiga/PtLib developers worked with the available documentation to get a "workable" result. On Tue, 13 Jan 2009, Julien Puydt wrote: Damien Sandras a écrit : However, having a pulseaudio plugin would fix a few problems. Fixing my gstreamer code would get us that. Snark on #ekiga ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- 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] Yet an other post on Pulseaudio
Hi, I think that we have to recognise that pulse audio is here to stay. Yes, pulseaudio has design issues. Take for instance pulseaudio on ubuntu 8.10. I cannot see how to direct pulseaudio to put sound from one app to one audio device , and sound for a different app to a second audio device. --- Asking users to remove pulse audio to make ekiga work is not an option. On some distributions, taking the pulse audio package off will remove a whole host of other packages. The only reasonable solution is to write a pulse audio plugin for ptlib. But I was reading elsewhere from some "expert" who said that if you have alsa code that works, you should not need to write anything. Last time I looked on the pulse audio web page, there was no information on writing a pulse audio plugin for reading&writing sound. Can anyone provide a definitive web page on how to write a valid pulse audio plugin? If you can provide a definitive web page on writing a valid pulse audio plugin that does record and play correctly, then I can write a pulseaudio plugin. == We have had over the years numerous sound systems on linux. OSS, ESD, ARTS, jack, alsa, pulseaudio, coreaudio come to mind. Admittedly, some are based on others.. Yet, after years of development, we have no clear winner as being suitable for the desktop. Since sound is a crucial part of gui applications, and since sound deos not work reliably on linux, I find it ludicrous to think that Linux is ready for the masses. Some users have to write custom asound.conf files. Some have to disable pulseaudio. Conclusion: Should windows users switch to linux, they will have to battle hard to get basic things (like sound) to work. Question: Is the deficiencies of audio in ekiga Damien's, or the plib/opal authors fault? No, these people all struggled hard with appalling documentation to write something that worked. Derek. On Sat, 10 Jan 2009, Andrea wrote: Damien Sandras wrote: Le samedi 10 janvier 2009 à 13:03 +, Andrea a écrit : Hi, I was just wondering is anybody has found a more friendly way to let ekiga work with pulseaudio. Would the support for oss help? I don't think so. Perhaps you should report the problem to the pulseaudio guys. First I need to learn how to disable pulseaudio, then I will have a better clue where the issue is. Cheers ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- 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] Looking for Quicknet card SIP client
Hi, nixj is in the openh323 project's cvs. http://sourceforge.net/projects/openh323 It is at the top level, beside openh323, pwlib, ixj, nixjsdk.. it does not work on 2.6 kernels. I abandoned developing nixj at the time of the transition to 2.6 kernels. In theory, with a 2.4 kernel, nixj will be "usable" within the line interface environment of openh323... I expect you will have to cut/modify code to make it work.. and I should be able to hack together Exactly. You will have to hack some code. Good luck. Derek. On Fri, 14 Nov 2008, [EMAIL PROTECTED] wrote: Hey Derek, Thanks for the very detailed reply, I'm sure you're right but I have a quicknet card and it works more or less. I also just picked up some IP phones for cheep and am trying to get a little PBX set up at home so I can stop paying Quest $70 / mo for one land line. Like many I've played around with Asterix here and there but didn't get too far with it. A while back I installed freeswitch and it basically worked out of the box. BTW there are a whole slew of soft PBX switches out there now, I've made a list. What I want to do now is continue to use the one analog wall phone in the kitchen without going through the hassle of buying yet another FXS/O? adapter since I already have one in my junk box. I've used this linejack board before on h323 calls to friends in asia and it worked ok, maybe not great but well enough. So all I need is the driver code for a current SIP project like Ekiga and maybe the NIXJ drive for the kernel and I should be able to hack together something that acts like an extension on freeswitch or any other softpbx. Thanks for your help, Clif On Sat, 15 Nov 2008, Derek Smithies wrote: Hi, You mention the IXJ driver.. Which implies linux.. I worked on a rewrite of the IXJ driver and called it nixj. IXJ contains horrible races, and is not SMP safe. IXJ has been ported to the 2.6 kernel series. I think it is fair to say that the driver has been ported to the 2.6 kernel api, but not tested. If you want to use nixj - you will do best with redhat 9.0 kernel.. nixj was developed on rh9. the quicknet cards were horrible for sound quality. They did not have the dynamic range of a normal sound card. I was once involved in a commercial project with quicknet cards. The cards were connected to an external mic&speaker. Users had to be careful to speak at the right volume. too loud or too quiet - and the card did not pick up the audio, or garbled it. Replaced quicknet cards with cheap sound cards - much better. Users could whisper - or shout - and the audio still got through.. So - why do you want to use quicknet cards? *Ability to do g729 or g723? Get a software codec - they are available for linux. *Ability to do DTMF decoding? The cards were not reliable - I had cases where it gave an answer that was 1 less than correct.. ptlib has dtmf detection routines that work just fine. One last thing: The card does not generate interrupts. The driver has to busy check for audio packets from the card. You will get gaps in the audio. I am sorry, but quicknet is a bad way to go. Very Very Very Very bad. Derek. On Fri, 14 Nov 2008, [EMAIL PROTECTED] wrote: Greetings, I've been looking for a somewhat current SIP client for the old Quicknet cards which are still supported in the Linux kernel via the IXJ driver. Ohphone still supports them but that is H323, and I would prefer to use SIP. I see that once upon a time Ekiga/Gnomeeting had drivers for these cards, could someone point me at that code or perhaps another sip project that still supports them? I'm just looking for the endpoint SW not a PBX so Asterix would be a little bit overkill for me. Thanks a bunch, Clif ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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 ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] Looking for Quicknet card SIP client
Hi, You mention the IXJ driver.. Which implies linux.. I worked on a rewrite of the IXJ driver and called it nixj. IXJ contains horrible races, and is not SMP safe. IXJ has been ported to the 2.6 kernel series. I think it is fair to say that the driver has been ported to the 2.6 kernel api, but not tested. If you want to use nixj - you will do best with redhat 9.0 kernel.. nixj was developed on rh9. the quicknet cards were horrible for sound quality. They did not have the dynamic range of a normal sound card. I was once involved in a commercial project with quicknet cards. The cards were connected to an external mic&speaker. Users had to be careful to speak at the right volume. too loud or too quiet - and the card did not pick up the audio, or garbled it. Replaced quicknet cards with cheap sound cards - much better. Users could whisper - or shout - and the audio still got through.. So - why do you want to use quicknet cards? *Ability to do g729 or g723? Get a software codec - they are available for linux. *Ability to do DTMF decoding? The cards were not reliable - I had cases where it gave an answer that was 1 less than correct.. ptlib has dtmf detection routines that work just fine. One last thing: The card does not generate interrupts. The driver has to busy check for audio packets from the card. You will get gaps in the audio. I am sorry, but quicknet is a bad way to go. Very Very Very Very bad. Derek. On Fri, 14 Nov 2008, [EMAIL PROTECTED] wrote: Greetings, I've been looking for a somewhat current SIP client for the old Quicknet cards which are still supported in the Linux kernel via the IXJ driver. Ohphone still supports them but that is H323, and I would prefer to use SIP. I see that once upon a time Ekiga/Gnomeeting had drivers for these cards, could someone point me at that code or perhaps another sip project that still supports them? I'm just looking for the endpoint SW not a PBX so Asterix would be a little bit overkill for me. Thanks a bunch, Clif ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] Ridding oneself of pulseaudio
Hi, I think the solution of removing pulse audio is a bit extreme, but I accept that it is effective. I have seen comments about ubuntu sound in 8.04 is not well setup for pulse audio. In my experience, this is true. Further, with multiple sound cards it is even harder. I was reading at https://wiki.ubuntu.com/PulseAudio that one has to write an /etc/asound.conf file which specified that pulse audio is used everywhere. Apparently, you have to make all users members of the various pulse related groups (pulse/pulse-rt/pulse) Perhaps the real solution is to add a pulseaudio plugin to ekiga. Ideally, plugins for ptlib are written in whatever language you like. It was the original hope of plugins that they do not depend on ptlib. Thus, when you upgrade ptlib the plugins don't need changing. Now, anyone willing to write a pulseaudio plugin? Required knowledge: C Does not require C++/ptlib knowledge. Derek. On Thu, 3 Jul 2008, Ryan Hughes wrote: Hi. I've been seeing some traffic (and generating some) about this Ubuntu/Pulseaudio bug. I can now use Ekiga, and I'll tell you how. 1) I apt-get remove'd pulseaudio. It was sad, because I like the ability to turn flash's sound down and rhythmbox's up. But I'll have to wait a release or two. Or hammer pulseaudio into Ekiga one day. Anyway, this next step I've never seen anyone propose before. 2) Removing pulseaudio left my sound working, but when I tested sound capture, it gave me that "unable to construct pipeline" error. I did this: asoundconf unset-pulseaudio and that made the difference. Now I can use Ekiga no problem. Thanks. --Ryan ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] IAX2 support (was (Re: [Ekiga-devel-list] Ekiga 3.00 available for WIN32 *only*)
Hi, On Fri, 4 Apr 2008, Rene Bartsch wrote: >> >> I think all he wanted to say was: Nobody who does not *want* to use SIP >> but would rather prefer IAX2 (for example, because he's behind a NAT >> firewall and has problems to make STUN work properly) will not be forced >> into SIP anymore. > > Yes, I just want to be able to connect to anyone with SIP. > > Mmh, I never tried whether IAX clients can work work peer-to-peer (with > some DNS tricks it's possible with any SIP client). They can work peer to peer. The iax2 protocol does allow for p2p. Difficulty is that iax2 (as a voip protocol) is part PBX protocol, and there are many PBX things bound into iax2 that (my view) don't belong there. > >> If IAX2 will marginalize SIP (as SIP did with H.323) is to be seen. SIP never maginalised h.323 because of better technology. Sip marginalised h.323 cause of better publicity. However, lets us avoid timewasting h.323 vs sip discussions. I will simply quote Craig Southeren "I have implemented both protocols. They are both overly complex. I hate both of them". There is some iax2 code in the opal trunk true, and in branch v3_2. I have just integrated it better into opal's call phase model. So, Iax2 can be made to work in Ekiga. Anyone interested in fixing the rough edges, and making it work? > - VSPs: Less horsepowers on the VoIP servers > - Hardware vendors: Much cheaper hardware > - Users:Much more reliable, only one NAT-port > > By the way, about three years ago I did some testing with IAX and SIP. > On a Server (Intel P4, 1024 MB RAM, 100 MBit/s inernet connection) I had > set up an Asterisk installation with facsimile support. The server was > connected to a PSTN gateway of a VSP with SIP and IAX. Then I tried to > send 10 facsimilies from a facsimile machine (FAX (analogue) -> ISDN -> > PSTN -> PSTN Gateway -> Internet -> Asterisk server). The latencies > between PSTN gateway and Asterisk server were about 5 -10 msecs. > > With IAX eight facsimilies were successful, SIP failed completely! No. This is an implementation issue of the SIP/fax/iax. The packets still take the same time to go over the network. The latency should be the same. Sip has been correctly described as the largest denial of service attack on the IETF working process. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] A couple ekiga annoyances
On Fri, 25 Jan 2008, Ken Restivo wrote: > > Thanks! Although there is no + key on any telephone that I know of, I > can imagine that they (and dashes) might be legal in SIP URL's. > Commonly, the + plus key is used to indicate international phone dialing. >From my signature - the phone number is ph +64 3 365 6485 In New Zealand, you dial 00 to get international calls (so + indicates 00) In other countries, the + indicates a different dialling sequence (to get international calls). Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] text-based version
Hi, Use ohphone, which is in the contrib directory of the cvs for pwlib/opal. For details on grabbing the code, go to www.voxgratia.org, suck down the libs and ohphone and build away... ohphone will have many of the features of ekiga - it is a matter of hunting for the right parameter etc to make it work. Derek. On Fri, 5 Oct 2007, Sauro Cesaretti wrote: > Hello everyone, > > I'd like to know if there is a version of ekiga that I can use in text-mode > under linux. > If not, can you suggest me anotger software in text-mode that perform the > same task? > > Thanks in advace > best regards Sauro > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.488 / Virus Database: 269.14.0/1048 - Release Date: 03/10/2007 > 20.22 > > > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] Speex codec
Hi, I think there was a memory leak at one time in Speex. Can you rerun the test, and examine the process size of ekiga please. Derek. On Wed, 2 May 2007, Typhoon wrote: > Sometime back there was a discussion of the Speex codec. I just had a > short conversation with another Ekiga user. The sound was fine for a > minute or two, then began to "stutter" and became unusable. > > I disabled the Speex codecs and re-connected with GSM and everything > worked fine. > > I'm on Debian Etch, Ekiga 2.0.3. and I don't have any clues as to what > might be wrong. > > Cheers, > Alan > ___ > ekiga-list mailing list > ekiga-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] Linux Journal article on Ekiga and Wengo
Hi, On the topic of reviewers: I was talking to the lead developer in a totally separate project, and he said that he made sure to provide "reviewers notes". He further commented that it was a point of continual surprise how many reviewers just copied verbatim from the notes and used that in the article. I would suggest that to prevent further "silly press" someone writes some notes suitable for a reviewer. Derek. On Thu, 15 Feb 2007, George Boyd wrote: > The problem I believe,is when reviewers test and compare software (in this case the article you mentioned), is that the reviewers are not fully aware of the potential or features of the software they are writing about. Reviewers should know the programs completely before they try to write comparison articles. Ekiga can be used with ANY sip service that allows inbound sip, with pbx's, and h323 gateways. It would be ridiculous to program Ekiga to be able to register (or in this article pay for pc>pstn credits) from the program to all of the services it can use, since all of the services use a different method to register (or pay). And I don't think Linux users are so stupid they can't figure out how to go to a site and register or pay, although this article seems to imply that. If you see my signature at the end of this message, all of these services I use with one program, EKIGA!! I can use any one, or all of them at the same time. There are many more then just these services that can be used. As far as WengoPhone or Gizmo, or any of the others. my best experience is with Ekiga. If you look again at my signature, you will see that Ekiga also works with Gizmo :) Ekiga can be used to connect to windoze users that use micro$ofts new version of the old msn messenger too (micro$oft finally had to join the mainstream and make a messenger that was SIP compatible) :) I think there is a WIKI for Ekiga that shows the services and how to set them up that have been used by Ekiga users. I know of no other program (windose or Linux) that has all the capabilities that Ekiga does. As far as audio quality, like you asked. I wonder what codec they were using, and through what service. As far as installation, how hard is it really to use any of the modern methods, such as Yum, etc to install the software, or to download and install 3 rpms and go through the installation druid? As far as the Linux community goes and with the installation instructions on Ekiga's site, it's also very simple to compile and install from source (even if you've never done it before). I wish these reviewers had enough sense to be intelligent. > Anyway, just thought I'd mention it on the list so that you're aware > of coverage. > > Oisín Feeley > ___ > ekiga-list mailing list > ekiga-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list Fedora Core 6 Linux Ekiga Rocks!! One program so many ways to connect! sip: [EMAIL PROTECTED] (or [EMAIL PROTECTED]) H323: gk.voxgratia.net:1719 geboyd53 SipBroker: *673-617808 -or- *011-1617808 (alias 617808) e164: +13606660349 or +882 398265 (linked to ekiga) Voipbuster: geboyd53 (chat), 13606660349 (telephone) Forward: 781549 Voxalot: 106153 Gizmo: 17476918163 ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] Ekiga 2.04 and ALSA
Hi, sound on linux continues to be a problem. In some of my darker momements, I have mispronounced "ALSA" as "ulcer". So where is real problem? The alsa plugins in pwlib follow the alsa examples, and "should" be correct. Then a bit of reading finds that between alsa 1.0.10 and 1.0.11 (or was it 1.0.11 and 1.0.12?) that the alsa internals were changed to add an extra dmix operator in the system asound.conf and I just don't get it. Do we decide that the direction of alsa is not right for this project and work on a openal based plugin. Will that be more reliable ? = On Wed, 31 Jan 2007, Rene Bartsch wrote: > Maybe you have to edit you asound.conf ... An activity which is technically challenging, and not for the faint hearted. Further, upgrades to your box will have an unknown outcome. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] Very choppy sound with sip:[EMAIL PROTECTED]
Hi, I wonder if you can make an audio only call to the sip:[EMAIL PROTECTED] address. find a second computer with a microphone attached, and record the sound that comes out the speaker. If we can see a regular pattern in the sound, or such, it will be possible to work out the cause of your sound issues. My suggestion is to put the sound you recorded into analysis software (audacity is a great start) and look for periods in the sound. My guess: There is a regular 30ms pattern in the sound. 20ms on, and then 10ms off. Weird things with alsa exist. - I have one particular alsa setup that demands the audio supplied to it is in 20ms chunks, which conflicts with those codecs that use 30ms chunks. It is a long story on that one, and results in time modifying /etc/asound.conf Derek On Tue, 16 Jan 2007, George Boyd wrote: > Are you using video when you make your calls? 50 KB/s upstream isn't > quite enough if you are using video and have the quality or frame rate > set very high. > > I'm not sure if I asked you before, but you might try using GSM instead > of ilbc if your VOIP provider uses it. Also if your VOIP provider uses > SPEEX narrow, that will help a lot too. > > I'm using cable (1 megabyte download, 356 kilobytes upload and on some > connections using video, it's still not enough if I'm also using one of > the audio codecs that are high bandwidth hogs plus high quality video. > > Also, if you don't mind making your video smaller, that will cut down on > a lot of your band width uses. > > Also, if your talking to friends that are using standard analog modems, > that can also create the problems you describe if they aren't using one > of the low bandwidth audio codecs (or are trying to use video too with > the video quality and frame rates set to high). > > I hope this info will help you in resolving your problems with the > audio. > > If there is anything else I run across that may help you, I will let you > know, > > Good Luck, > George > > > > >300 KB/s downstream, 50 KB/s upstream, where 1 KB = 1,024 bytes. > > > >GnomeMeeting 1.2.2 used to work fine on this connection, and so > > does Skype (well, as fine as Skype can work). > > > ___ > ekiga-list mailing list > ekiga-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] Video and Linux to Windows
Hi, Run MyPhone on the windows box. this program is a MFC frontend to the openh323 and pwlib libraries, so allows you to run h.323 on a windows box. It uses the windows codecs, so you can do g.723.1 and g.729 on windows. Note, with some windows codecs, you need to set the audio buffer depth to 6. It is available from pacphone (sorry, don't have the links) or sourceforge. Derek. == On Fri, 1 Sep 2006, Carles Pina i Estany wrote: > > Hello, > > Soon I will need to connct Ekiga/Linux to something/Windows, with audio > and video (two ways) > > I know that there is a Ekiga for Windows (beta). I wonder if somebody > knows other programs to execute on Windows supporting SIP (audio and > video). > > Which program people prefers, apart of Ekiga, to execute on Windows? > > Thank you very much, > > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] 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] Installation problem with pwlib
Hi, On Sun, 6 Aug 2006, Damien Sandras wrote: > I do not understand how you can compile OPAL without PWLIB. It is > impossible. You have to first compile pwlib, then opal, then ekiga. If > you are not doing so, and that it works, you will get a crashy binary > because of libraries conflicts. Technically, Damien, I agree with you. However, I suspect that Ludovic has *the pwlib and pwlib-dev packages on this box, *possibly has the opal and opal-dev packages on his box. and is then compiling the source extracted from an opal tarball. the source he is compiling is including headers from pwlib-dev. the source he is compiling may be including headers from opal-dev the source he is compiling may be including headers from the tarball. This is not guaranted to work. In fact, it is a sure and accurate path to madness. My suggestion:: When compiling pwlib/opal etc, remove all packages pertaining to pwlib/opal-dev. Derek. > Hi, > > Le vendredi 04 août 2006 à 20:47 +0200, Ludovic Gris a écrit : > > Hi, > > I have problem to install ekiga from source on my slackware 10.2. > > I installed packages from linuxpackages.com and I have problem with > > gconf. Someone on the mailing list from linuxpackages has the same > > problem and indicate that it works when installing from sources. > > So I try... > > Opal is now installed from source but I have problem with pwlib-1.10.1. > > I do not understand how you can compile OPAL without PWLIB. It is > impossible. You have to first compile pwlib, then opal, then ekiga. If > you are not doing so, and that it works, you will get a crashy binary > because of libraries conflicts. > > > > I don't know why and don't find information about such a problem on the net. > > I make: > > ./configure --prefix=/usr --enable-plugins --disable-oss --enable-v4l2 > > and > > make >> make.log 2>&1 > > Here is a few line of "make.log" : > > > > I think it is a problem with the headers of the kernel. There was some > post about that on the mailing list a while ago : > http://mail.gnome.org/archives/gnomemeeting-list/2006-May/msg00055.html > with the solution : > http://mail.gnome.org/archives/gnomemeeting-list/2006-May/msg00106.html > > -- Derek Smithies Ph.D.ClueCon - The open source conference IndraNet Technologies Ltd. for telephony Email: [EMAIL PROTECTED] Chicago, 1-3 August 2006 ph +64 3 365 6485http://www.cluecon.com Web: http://www.indranet-technologies.com/___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
