Re: [h323plus] H323AudioCodec::SetRawDataHeld

I'm sorry but I definitely don't understand what you mean when you say 'the timedmutex is there to avoid locks'. Which kind of lock ? The PTimedMutex is a local variable here and I can't understand its purpose... I would really appreciate your explanation because my C++ skill doesn't allow me to find the answer :-)

The hold function works fine most of the time but it happens to hang or to be slowed. It is quite os-dependent : on my XP box, it's hard to make it fail but very easy on vista. I also encoutered such starvations on linux.

A patch could be to set an indirect channel on the codec and, when holding/retrieving the call, using this indirect channel to swap instead of asking the codec. No ?

Thanks for your answer!

Sebastien

Simon Horne a écrit :

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

---

Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte.