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
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
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.
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.
Sébastien
You need to subscribe. It's ok now I manually added you to the mailing list. :)
Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of Sébastien Annedouche Sent: Monday, 12 November 2007 5:15 PM To: h323plus@lists.packetizer.com Subject: Re: [h323plus] H323AudioCodec::SetRawDataHeld
Thanks for your answer Simon.
Am I not sending this mail to the developer list (h323plus@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@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.
participants (2)
-
Simon Horne
-
Sébastien Annedouche