[h323plus] H323AudioCodec::SetRawDataHeld

Sébastien Annedouche sannedouche at c3t.fr
Fri Nov 9 12:49:21 EST 2007

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!


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 at lists.packetizer.com
> [mailto:h323plus-bounces at lists.packetizer.com]On Behalf Of Sébastien
> Annedouche
> Sent: Friday, 9 November 2007 10:01 PM
> To: h323plus at 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.

More information about the h323plus mailing list