Re: [Iaxclient-devel] Re: Problems with libiax

[Andre B. <ast...@km...>]

Hi Steve, i use the lcc Win32 Compiler for by C Source. I had also memory=
 of problems in my first nonreleased Versions. There was
some Problems with freeing of iax_frames but i=B4m not sure. It=B4s long =
time ago.

My Sound Output is currently in Delphi GUI because i have never Programme=
d C before this. It was only to try the DirectX API for
Output. (This was my first App with DirectX). Now i know enough about C t=
o write the Soundoutput directly in C like an
Phonecore(GNOPhone) modul.

The bad Quality comes from my hardcoded Buffersize. On some Computers i f=
ix this Problem with a recompile and a bigger Outputbuffer.
There a big problems too on Win32 and DirectX. On the Snomphone you have =
nearly zero latency for the Sound Output. On DirectX i have
to fill a Ringbuffer with the Audiodata. And there i have my bigest Probl=
ems the Thread timing on Win32 is terrible. If i have a
Ringbuffer with 2 160byte Chunks, i have many buffer underruns if i minim=
ize and maximize any Windows. I see currently no
Soundapplications with a smaller Latency than 50ms and DirectX, because t=
he Threading on Windows makes it impossible. I have try an
Thread Priotity Realtime but i have still always bufferunderuns if i mini=
mize or maximize some Windows. I think Microsoft=B4s Window
animation have a higher priority as a Realtime Application.
With a higher Latency and a bigger Buffer i have no Problems with the Aud=
io quality.

I think the your Library need some Abstraction Parts for Threads and Thre=
ad Syncronisation. It is not very difficult to Implement a
PThread for Win32. Same with Mutexes. I didn=B4t know anything about Mac,=
 so i can talk only about my Win32 Problems.

Sorry my English :)

Andre

----- Original Message -----
From: "Steve Kann" <st...@St...>
To: "Shawn Lawrence" <sha...@te...>
Cc: <iax...@li...>; <mar...@di...>
Sent: Monday, March 03, 2003 11:40 PM
Subject: [Iaxclient-devel] Re: Problems with libiax



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

> 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's
> 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's easily solvable by adding a little bit of threading to the libra=
ry
> itself.
>
> So to sum things up, Mark's comments weren't that far off.  The malloc
> 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's happening on the other platforms.  I am hoping to perf=
orm
> 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't believe in putting something out =
that
> doesn't work properly.  I did have plenty of ideas on where to go and d=
id
> 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're dealing with these issues now and not
> somewhere down the pipe.
>
> 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

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


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugg=
er
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNI=
X
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Iaxclient-devel mailing list
Iax...@li...
https://lists.sourceforge.net/lists/listinfo/iaxclient-devel