[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!
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.
>
>
>
>
>
More information about the h323plus
mailing list