Re: [Ekiga-list] PTLIB alsa plugin status

[Alec Leamas <leamas alec gmail com>]

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

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?

--a