[h323plus] H323AudioCodec::SetRawDataHeld

[Simon Horne]

Sébastien

You need to subscribe. It's ok now I manually added you to the mailing list.
:)

Simon


-----Original Message-----
From: h323plus-bounces at lists.packetizer.com
[mailto:h323plus-bounces at lists.packetizer.com]On Behalf Of Sébastien
Annedouche
Sent: Monday, 12 November 2007 5:15 PM
To: h323plus at lists.packetizer.com
Subject: Re: [h323plus] H323AudioCodec::SetRawDataHeld


Thanks for your answer Simon.

Am I not sending this mail to the developer list
(h323plus at lists.packetizer.com) ?


Sébastien Annedouche

C3T - http://www.c3t.fr


Simon Horne a écrit :
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.







----------------------------------------------------------------------------
-----------
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.