Re: [Opalvoip-devel] Clearing calls lasts more than 2 minutes

[Denis L. <den...@go...>]

Hi Hartmut,

I also recognized a very high CPU load, but I thought that it is
caused by the video stream. But I had also a high load when I am not
making a video call. However, I have only tried the hole thing in a
virtual environment. I'll try it on a physical machine the next days.
I hope, that I can provide some results and log files afterwards.

Thanks for your help. Know I have something where I can look for.

Denis

2011/8/9 Hartmut Neumann <har...@hm...>:
>
>
>
> Hallo Robert, Denis,
>
> I have a similar problem with an Opal application running on an ARM Linux
> platform (the problem does not exist with old Opal / Ptlib versions of the
> year 2009).
> It also could take a long time (minutes) that the alsa sound channel has
> been closed.
>
> The media patch threads have an  high priority and could consume much CPU
> time.
> If the media streams for read and write with Alsa sound channels don't work
> optimal the media patch threads for read and write are running or blocking
> by the Alsa device.
>
> And if the media patch thread is blocked, e.g. the PCM Write operation, it
> occupies the device_mutex.
>
> PBoolean PSoundChannelALSA::Write(const void *buf, PINDEX len)
>
> {
>
> PWaitAndSignal m(device_mutex);
>
> ....
> }
>
> The media patch thread is running or occupies the device mutex.
>
>
> The thread which controls the call and clears the call has the normal
> priority.
> Clearing the call the control thread tries to close the sound channels
> (read and write) by the Close operation which waits for the device_mutex.
> But this is only possible in a gap. If the device_mutex is not occupied and
> no media patch thread (high priority) is running.
>
>
> PBoolean PSoundChannelALSA::Close()
>
> {
>
> PWaitAndSignal m(device_mutex);
>
> ...
> }
>
>
> I have only found a work around for the problem.
> When I implement a sleep
>
> PThread::Sleep(1);
>
> in the while loop of
>
> void OpalMediaPatch::Main()
>
> Clearing the call is much faster. I think the problem has to do with the
> Alsa device.
>
> We have a performance problem with the Alsa device in our application. I
> don't know yet how to fix the problem.
>
> Best Regards
>
> Hartmut Neumann
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Robert Jongbloed [mailto:ro...@vo...]
> Gesendet: Mittwoch, 3. August 2011 07:57
> An: opa...@li...
> Betreff: Re: [Opalvoip-devel] Clearing calls lasts more than 2 minutes
>
> Looking at the log file I see:
>
>
>
>   1:05.177                         simpleopal2
> connection.cxx(488)     OpalCon               OnReleased
> Call[C8c5e790e1]-EP<pc>[P88de088c2]
>
> ...
>
>   1:07.921                         simpleopal2
> sound_alsa.cxx(375)     ALSA      Closing default
>
>
>
> Which is nearly three seconds to do something that should be done in a
> millisecond. Unfortunately, I have no idea why it is taking so long.
>
>
>
> Yes, the Clear() is supposed to return pretty much immediately. The network
> negotiations are definitely done in the background as they will always take
> time. There are some things like closing the sound device which is not done
> in the background as it is not expected to take long. In your case, for some
> reason, it is taking a very long time.
>
>
>
> As I am unaware of anyone else having this problem, I would guess it is
> something to do with your platform or sound drivers. All I can suggest is
> you start adding trace logs to narrow down where it is getting delayed and
> stuck.
>
>
>
> Sorry I can’t be of much more help.
>
>
>
> Robert Jongbloed
>
> OPAL/OpenH323/PTLib Architect and Co-founder.
>
>
>
> From: Denis Loh [mailto:den...@go...]
> Sent: Tuesday, 2 August 2011 5:59 PM
> To: Robert Jongbloed
> Cc: opa...@li...
> Subject: Re: [Opalvoip-devel] Clearing calls lasts more than 2 minutes
>
>
>
> I am still trying to track down the problem. I rewrite the hole code, that
> the main thread is the only one which works with calls. That has shown me
> some other issues, but did not solve the hangup problem.
>
> The code from my initial email has changed to:
>
>         PString & token = currentCallToken.IsEmpty() ? heldCallToken :
> currentCallToken;
>
>         if (!ClearCall(token)){ <-----------------------------
>
> ------------------------- it hangs here.
>
>           Command.ReturnCode = OpalSocketInterface::NOK;
>           Command.Return = "No call to hangup";
>         }
>         else {
>           Command.ReturnCode = OpalSocketInterface::OK;
>
>           Command.Return = "Call " + token + " cleared\n";
>           PTRACE(4, "Call cleared");
>         }
>
> I tried to understand what ClearCall actually does. But when I read you
> comments in the code, the function should return immediately and opal is
> clearing the call in background.
>
> This seams to be done, but not completely. I attached the output log with
> PTRACE level 5.
>
>
>
> 2011/7/6 Robert Jongbloed <ro...@vo...>
>
> As this does not happen with any other application, I have to assume it is
> something in your program.
>
>
>
> The one thing that can happen easily is deadlocks/starvation due to the call
> back virtual functions you may be intercepting can happen in a variety of
> internal threads within OPAL. It is up to the application to make sure it
> can deal with that. If you look at something like OpenPhone, it ends up
> packing up the virtual call back and sending a windows message so it can be
> processed in the main thread to avoid complicated deadlocks with the
> Windowing system.
>
>
>
> If you wish a simpler, thread safe API, I would suggest using the interface
> available in opal.h, which will do all the serialisation needed to avoid
> threading issues.
>
>
>
> Robert Jongbloed
>
> OPAL/OpenH323/PTLib Architect and Co-founder.
>
>
>
> From: Denis Loh [mailto:den...@go...]
> Sent: Tuesday, 5 July 2011 10:31 PM
> To: opa...@li...
> Subject: [Opalvoip-devel] Clearing calls lasts more than 2 minutes
>
>
>
> Hi,
>
> I have written a voip client based on simpleopal. While simpleopal works
> fine in most cases, my own creation hangs when I try to clear the call.
>
>