Re: [Ekiga-list] PTLIB alsa plugin status
- From: Alec Leamas <leamas alec gmail com>
- To: Ekiga mailing list <ekiga-list gnome org>
- Subject: Re: [Ekiga-list] PTLIB alsa plugin status
- Date: Wed, 25 Feb 2009 09:07:51 +0100
Derek Smithies wrote:
>>> - Playback and record thread are synchronized in a way that
forces the two
This mutex is important, and should not syncrhonize the play&record
Yes - can someone test that ptlib alsa plugin works ok with this
streams to wait for each others I/O operations.
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.
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?
] [Thread Prev