Re: [Ekiga-list] PTLIB alsa plugin status

Derek Smithies 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??
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?


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