The TimedMutex is there to avoid locks.
From my experience the hold function works fine for audio. With the addition
of Video on Hold (VOH) in H323plus things seem to happen much as you described. There is quite a lot going on to swap out the media channels. I really have not had the time to investigate it further and is one of the many things on my to-do list.
Patches are welcome.
Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of Sébastien Annedouche Sent: Friday, 9 November 2007 10:01 PM To: h323plus@lists.packetizer.com Subject: [h323plus] H323AudioCodec::SetRawDataHeld
Hi,
my question might be stupid but can someone explain why a mutex is used in the SetRawDataHeld method :
BOOL H323AudioCodec::SetRawDataHeld(BOOL hold) {
PTimedMutex m; m.Wait(50); // wait for 50ms to avoid current locks IsRawDataHeld = hold; m.Wait(50); // wait for 50ms to avoid any further locks return TRUE; }
I have another problem concerning codecs. Codecs sleep during read and write (within ReadRaw et WriteRaw) keeping rawChannelMutex locked and they lok it again immediately after signalling. I encouter thread starvations (or at least very long time before getting method called) when I try to call addFilter or SwapChannel on a running codec. This behavior can, for instance, prevent me from holding a call. Does anyone have this same problem ?
Thanks for your help,
Sebastien