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
_______________________________________________
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list
