Re: [Ekiga-list] PTLIB alsa plugin status

Derek Smithies wrote:
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:

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

Hey! Have I said it's something wrong with threads? I have actually my background in tecknical systems, I was using threads long time before the word was used :-) I was just raising a question, and you have answered it. The PTlib alsa driver is defined as reentrant. I have no problems with this, once I understand it (it might be useful to document this fact in the PSoundChannel interface, I doubt I'm the only one which will stumble into this).

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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]