Sebastien
I think is this case the PTimedMutex is being used as a PProcess::Sleep(50)
and not as a PTimedMutex. You will see a few PProcess::Sleep(50) further in
the implementation. I'm experiencing the same issues you are describing. the
difference on the OS's is somehow related to how PTimedMutex is interpreted.
For instance generating DTMF tones seperated with PTimedMutex seems to be
handled differently on XP and Vista. I haven't had the time to investigate
this further.
PS. It's a good idea to join the h32plus developer's list
http://www.h323plus.org/lists.html so I don't have to approve the post. :)
Simon
-----Original Message-----
From: Sébastien Annedouche [mailto:sannedouche@c3t.fr]
Sent: Saturday, 10 November 2007 1:49 AM
To: Simon Horne
Cc: h323plus@lists.packetizer.com
Subject: 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.
---------------------------------------------------------------------------------------
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.