Re: [Ekiga-list] PTLIB alsa plugin status

[Alec Leamas <leamas alec gmail com>]

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

--a