[h323plus] H323AudioCodec::SetRawDataHeld

[Simon Horne]

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 at c3t.fr]
Sent: Saturday, 10 November 2007 1:49 AM
To: Simon Horne
Cc: h323plus at 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 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.
>
>
>
>
>