[Iaxclient-devel] Re: Problems with libiax

[Steve K. <st...@St...>]

Shawn, list,

I'm sure I'm kinda late to reply to this, and I don't have too much
constructive to say, other than to outline the priorities.

On Mon, Mar 03, 2003 at 01:07:16AM -0700, Shawn Lawrence wrote:
> I decided after our converserations late last week about trying to make=
 the
> code as common as we could across the various platforms that I should d=
o
> some performance testing on the current library and track down the Win9=
8 bug
> that you were coming across earlier.  As I had mentioned, I was going t=
o
> play with the winiphone package on Win98 to see if I could find out why=
 the
> audio packets were not sending.  I compiled the winiphone package (usin=
g the
> changes you sent) with VC 6 and managed to get the program to run witho=
ut
> any problems.  However, I came across some other issues that were extre=
mely
> disturbing.

I had thought that these issues were likely to be related to the
handling of the audio devices and stuff, and less so to the libiax code.
I could be wrong about that, and it may have some relation to timer
granularity and stuff on non-NT windows systems.

Certainly, I would say that the kinda hacky audio handling code in
"winiphone" would be a leading suspect for many problems.

> The first issue has to deal with a massive memory leak in the iax libra=
ry
> code.  This is caused by the malloc functions inside the event handling=
 code
> that keeps track of all the iax events as they are passed through the
> system.  To give you an idea, the program is swallowing up 50MB of memo=
ry
> after just over 3 minutes of audio transmission.  Over a 12 minute span=
, I
> managed to swallow up 172MB of RAM and managed to crash the application=
.  I
> checked both virt1800 and IAXPhone for the same problem.  The virt1800
> library exhibited exactly the same problem.  The IAXPhone package did n=
ot
> show the memory leak itself.  However, because they=92re using a DLL to
> provide the IAX functions and Delphi handles memory allocation differen=
tly,
> it is hard to tell if Andre has found this problem already or if Delphi=
 is
> just handling the memory better.  I will do some looking into the IAXPh=
one
> code and see if any changes were made.

A couple of things:

(1) Memory leaks like this are definatly no good, though nobody needs me
    to say that.

(2) I'd guess that in Andre's case, he used Delphi for all the GUI stuff
    (and audio stuff, I think), but he did use libiax itself in C
    underneath, and it's memory management would probably be defined by
    Windows' malloc implementation.  I suppose his compilation
    environment could have included a different malloc, but I doubt
    that.

(3) I wonder if miniphone under linux exhibits the same memory leak?
    That could easily help you narrow it down.



> Speaking of crashing the application, the library does not appear to be=
 very
> stable in its current state (at least on WinXP).  I was able to crash t=
he
> application without doing much at all.  I also found the same thing whe=
n I
> tried the virt1800 test application and the IAXPhone application.  The
> winiphone application was the only application that would exit normally
> after a call was made.  Both virt1800 and IAXPhone would report access
> violations after the application exited.

Again, I'd look into if these were audio device issues, or issues with
the core libiax code. =20

> Next, the CPU utilization is definitely a problem.  Andre was able to h=
elp
> deal with that problem by controlling the priority of the processing th=
reads
> he used to do the IAX communications.  The only problem I found with An=
dre=92s
> IAXPhone (at least the version I have) was the receive audio was really
> crummy while the transmit audio was fairly good.  I think this is an is=
sue
> that=92s easily solvable by adding a little bit of threading to the lib=
rary
> itself.
>=20
> So to sum things up, Mark=92s comments weren=92t that far off.  The mal=
loc
> functions in the libiax implementation will need to be looked over.  Th=
e
> only thing that concerns me is that if this is happening on the Win32
> platform, what=92s happening on the other platforms.  I am hoping to pe=
rform
> some tests with miniphone on Linux and see what the results are.  I did
> notice the miniphone code for the Linux console app was structured
> differently than the winiphone app.  I am going to take a closer look a=
t the
> differences when I do my batch of Linux testing.

The way I read what Mark said, he was talking about changing the libiax
code so that it didn't need to constantly call malloc for every event.
He didn't seem to indicate that there were problems that would cause
memory leaks.  While that's definately a good idea,  I don't consider it
the top priority unless it is actually causing performance problems.  I
also don't know what kind of architecture the SNOMs that Mark is
targeting have, but I suspect that they're considerably less
resourceful(?) than a full PC (both in terms of CPU and memory).  So,
the way I see it, dealing with allocation more efficiently (such as by
using a pre-allocated pool, etc), would be great, it's a separate issue
from the leaks you've had.

But the leaking you see on Windows might just be a bug in "winiphone".
Also, I suppose if you're receiving events much faster than you can
process them, and there's no good limits on how big the event queue can
get, you might just have a constantly increasing event queue.

> I wish I had better news, but I don=92t believe in putting something ou=
t that
> doesn=92t work properly.  I did have plenty of ideas on where to go and=
 did
> have things focused down so I could come to a conclusion by the end of =
the
> weekend, but I am glad I put the brakes on and did some homework to fin=
d
> these issues.  This way, we=92re dealing with these issues now and not
> somewhere down the pipe.
>=20
> Let me know what your thoughts are.  I am going to start working on a
> solution to the memory leak problems tomorrow.

My thoughts are that if the general interface to libiax is sound and
useful to us, we can always find and fix bugs in either the callers or
the library.  OTOH, if there's an architectural issue that will make
portability difficult, or make it difficult to implement necessary
features, that needs to be deal with very early.

-SteveK

--=20
  Steve Kann - Chief Engineer - 520 8th Ave #2300 NY 10018 -  (212) 533-1=
775
                HorizonLive.com - collaborate . interact . learn
   "The box said 'Requires Windows 95, NT, or better,' so I installed Lin=
ux."