Menu
▾
▴
iaxclient-devel
|
From: Steve K. <st...@St...> - 2003-03-03 22:41:00
|
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."
|
|
From: The S. <kc...@al...> - 2003-03-05 00:35:21
|
Hi everybody, I use bcb 6 to compile an new version of IAX lib from cvs .. This is work= ing but seems to have here and there some quarks .. ( at the moment i am struckling with (un) authenticated calls) My question now is .. are these problems applying to this version of the = iax lib as well ?? Or do you guys use an different cvs or versions that are outside digium cvs ?? As far as I can see This version I just resently obtained doesn't use dir= ect X, but native Api calls .. and to my first impression if I call my win32 iax client .. it sounds resenable .. Greetings KC Steve Kann wrote: > Thanks for writing back Andre! > > On Tue, Mar 04, 2003 at 04:49:59AM +0100, Andre Bierwirth wrote: > > Hi Steve, i use the lcc Win32 Compiler for by C Source. I had also me= mory of problems in my first nonreleased Versions. There was > > some Problems with freeing of iax_frames but i=B4m not sure. It=B4s l= ong time ago. > > > > My Sound Output is currently in Delphi GUI because i have never > > Programmed 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 to write the Soundoutput directly in C like an Phonecore(GNOPhone) > > modul. > > Thanks, that's what I expected, and remember from when I looked at your > sources. > > > The bad Quality comes from my hardcoded Buffersize. On some Computers > > i fix 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 Problems th= e > > Thread timing on Win32 is terrible. If i have a Ringbuffer with 2 > > 160byte Chunks, i have many buffer underruns if i minimize and > > maximize any Windows. I see currently no Soundapplications with a > > smaller Latency than 50ms and DirectX, because the Threading on > > Windows makes it impossible. I have try an Thread Priotity Realtime > > but i have still always bufferunderuns if i minimize or maximize some > > Windows. I think Microsoft=B4s Window animation have a higher priorit= y > > as a Realtime Application. With a higher Latency and a bigger Buffer > > i have no Problems with the Audio quality. > > Interesting. > > I think that, in our application, this should be something that is > tunable at runtime, or at least compile time. > > For our application, we'd happily bump up the latency by another 50ms o= r > 100ms, if it meant really good quality. > > Since I expect that many users will be using internet connections for > this, there's going to be several sources of latency in the whole > system: > > 1) Actual network transmission time: Somewhere from 2 - 2000 ms. > 2) The clients' Jitter buffer. > 3) The clients audio device buffer. > > Something we might want to look at later is to see if or how we can > "combine" 2 and 3? > > As far as audio driver technologies, I don't know what benefits DirectX > has over the "standard" windows audio interfaces, but we'll need to > support "out-of-the-box" Windows installations without needing them to > go and download and install DirectX, so we'll need to support the > standard windows APIs as a baseline. Then, if there's benefits to it, > we could detect the presence of compatible DirectX interfaces, and use > them, if the user already has them installed. > > > I think the your Library need some Abstraction Parts for Threads and > > Thread Syncronisation. It is not very difficult to Implement a PThrea= d > > for Win32. Same with Mutexes. I didn=B4t know anything about Mac, so = i > > can talk only about my Win32 Problems. > > First, Mac OS X is really very much like FreeBSD, except, in our case, > for Audio stuff, and GUI stuff. So, it fully supports pthreads. > > For Windows, it's my understanding that their threads and "critical > sections" are pretty similar to pthreads and mutexes. For another > project, we just do some #defines to make them act the same way, like > this: > > #ifndef _WIN32 > > #define SOCKET int > #define INVALID_SOCKET -1 > #define SOCKET_ERROR -1 > #define SD_SEND 1 > > #define INET_ATON(s, a) (inet_aton(s, &a) =3D=3D 0) > #define SOCKLEN socklen_t > #define SOCKETERRORMSG strerror(errno) > #define CLOSESOCKET(s) close(s) > > #define THREAD pthread_t > #define THREADIDDECL(t) > #define THREADCREATE(func, args, thread, id) \ > pthread_create(&thread, NULL, func, args) > #define THREADCREATE_ERROR -1 > #define THREADFUNCDECL(func) void * func(void *args) > #define THREADFUNCRET(r) void * r > #define THREADJOIN(t) pthread_join(t, 0) > #define MUTEX pthread_mutex_t > #define MUTEXINIT(m) pthread_mutex_init(m, NULL) //TODO: check = error > #define MUTEXLOCK(m) pthread_mutex_lock(m) > #define MUTEXUNLOCK(m) pthread_mutex_unlock(m) > #define MUTEXDESTROY(m) pthread_mutex_destroy(m) > > #else > > #define INET_ATON(s, a) ((a.s_addr =3D inet_addr(s)) =3D=3D INA= DDR_NONE) > #define SOCKLEN int > #define SOCKETERRORMSG get_WSA_error_str(WSAGetLastError()) > #define CLOSESOCKET(s) closesocket(s) > > #define THREAD HANDLE > #define THREADIDDECL(t) unsigned t; > #define THREADCREATE(func, args, thread, id) \ > (thread =3D (HANDLE)_beginthreadex(NULL, 0, func, (PVOI= D)args, 0, &id)) > #define THREADCREATE_ERROR NULL > #define THREADFUNCDECL(func) unsigned __stdcall func(PVOID args= ) > #define THREADFUNCRET(r) int r =3D 0 > #define THREADJOIN(t) WaitForSingleObject(t, INFINITE) > #define MUTEX CRITICAL_SECTION > #define MUTEXINIT(m) InitializeCriticalSection(m) > #define MUTEXLOCK(m) EnterCriticalSection(m) > #define MUTEXUNLOCK(m) LeaveCriticalSection(m) > #define MUTEXDESTROY(m) DeleteCriticalSection(m) > > #endif > > > Sorry my English :) > > Your English is fine, no apology needed! > > Thanks for joining the mailing list and helping! > > -SteveK > > -- > Steve Kann - Chief Engineer - 520 8th Ave #2300 NY 10018 - (212) 533= -1775 > HorizonLive.com - collaborate . interact . learn > "The box said 'Requires Windows 95, NT, or better,' so I installed L= inux." > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debu= gger > for complex code. Debugging C/C++ programs can leave you feeling lost a= nd > disoriented. TotalView can help you find your way. Available on major U= NIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel -- -------------------------------------------------------------- 12:03am up 356 days, 6 users, load average: 0.68, 0.43, 0.30 89 processes: 88 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 1.2% user, 1.2% system, 0.0% nice, 97.4% idle Mem: 257620K av, 130248K used, 127372K free, 56024K shrd Swap: 401584K av, 280K used, 401304K free 52548K cached |
|
From: Steve K. <st...@St...> - 2003-03-05 14:48:47
|
KC, There's several versions of things going around here, that people are talking about, most of which are referenced at http://iaxclient.sourceforge.net/ Andre's work is the IAXPHONE stuff, listed there, but he's still working on that port. There's a snapshot that i've mirrored on the iaxclient webpage. There is the Digium CVS, which has a kindof outdated and hacky Win32 "winiphone", which is really just a proof-of-concept kind of thing. Then, there's this new code we're trying to develop, which doesn't yet have any releases. =20 -SteveK On Wed, Mar 05, 2003 at 01:40:02AM +0100, The Sysop wrote: > Hi everybody, >=20 > I use bcb 6 to compile an new version of IAX lib from cvs .. This is wo= rking but seems to have here and there some quarks .. ( at the > moment i am struckling with (un) authenticated calls) >=20 > My question now is .. are these problems applying to this version of th= e iax lib as well ?? Or do you guys use an different cvs or > versions that are outside digium cvs ?? >=20 > As far as I can see This version I just resently obtained doesn't use d= irect X, but native Api calls .. and to my first impression if > I call my win32 iax client .. it sounds resenable .. >=20 > Greetings KC >=20 >=20 > Steve Kann wrote: >=20 > > Thanks for writing back Andre! > > > > On Tue, Mar 04, 2003 at 04:49:59AM +0100, Andre Bierwirth wrote: > > > 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 > > > Programmed C before this. It was only to try the DirectX API for > > > Output. (This was my first App with DirectX). Now i know enough abo= ut > > > C to write the Soundoutput directly in C like an Phonecore(GNOPhone= ) > > > modul. > > > > Thanks, that's what I expected, and remember from when I looked at yo= ur > > sources. > > > > > The bad Quality comes from my hardcoded Buffersize. On some Compute= rs > > > i fix this Problem with a recompile and a bigger Outputbuffer. The= re > > > 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 Problems = the > > > Thread timing on Win32 is terrible. If i have a Ringbuffer with 2 > > > 160byte Chunks, i have many buffer underruns if i minimize and > > > maximize any Windows. I see currently no Soundapplications with a > > > smaller Latency than 50ms and DirectX, because the Threading on > > > Windows makes it impossible. I have try an Thread Priotity Realtime > > > but i have still always bufferunderuns if i minimize or maximize so= me > > > Windows. I think Microsoft=B4s Window animation have a higher prior= ity > > > as a Realtime Application. With a higher Latency and a bigger Buff= er > > > i have no Problems with the Audio quality. > > > > Interesting. > > > > I think that, in our application, this should be something that is > > tunable at runtime, or at least compile time. > > > > For our application, we'd happily bump up the latency by another 50ms= or > > 100ms, if it meant really good quality. > > > > Since I expect that many users will be using internet connections for > > this, there's going to be several sources of latency in the whole > > system: > > > > 1) Actual network transmission time: Somewhere from 2 - 2000 ms. > > 2) The clients' Jitter buffer. > > 3) The clients audio device buffer. > > > > Something we might want to look at later is to see if or how we can > > "combine" 2 and 3? > > > > As far as audio driver technologies, I don't know what benefits Direc= tX > > has over the "standard" windows audio interfaces, but we'll need to > > support "out-of-the-box" Windows installations without needing them t= o > > go and download and install DirectX, so we'll need to support the > > standard windows APIs as a baseline. Then, if there's benefits to it= , > > we could detect the presence of compatible DirectX interfaces, and us= e > > them, if the user already has them installed. > > > > > I think the your Library need some Abstraction Parts for Threads an= d > > > Thread Syncronisation. It is not very difficult to Implement a PThr= ead > > > for Win32. Same with Mutexes. I didn=B4t know anything about Mac, s= o i > > > can talk only about my Win32 Problems. > > > > First, Mac OS X is really very much like FreeBSD, except, in our case= , > > for Audio stuff, and GUI stuff. So, it fully supports pthreads. > > > > For Windows, it's my understanding that their threads and "critical > > sections" are pretty similar to pthreads and mutexes. For another > > project, we just do some #defines to make them act the same way, like > > this: > > > > #ifndef _WIN32 > > > > #define SOCKET int > > #define INVALID_SOCKET -1 > > #define SOCKET_ERROR -1 > > #define SD_SEND 1 > > > > #define INET_ATON(s, a) (inet_aton(s, &a) =3D=3D 0) > > #define SOCKLEN socklen_t > > #define SOCKETERRORMSG strerror(errno) > > #define CLOSESOCKET(s) close(s) > > > > #define THREAD pthread_t > > #define THREADIDDECL(t) > > #define THREADCREATE(func, args, thread, id) \ > > pthread_create(&thread, NULL, func, args) > > #define THREADCREATE_ERROR -1 > > #define THREADFUNCDECL(func) void * func(void *args) > > #define THREADFUNCRET(r) void * r > > #define THREADJOIN(t) pthread_join(t, 0) > > #define MUTEX pthread_mutex_t > > #define MUTEXINIT(m) pthread_mutex_init(m, NULL) //TODO: chec= k error > > #define MUTEXLOCK(m) pthread_mutex_lock(m) > > #define MUTEXUNLOCK(m) pthread_mutex_unlock(m) > > #define MUTEXDESTROY(m) pthread_mutex_destroy(m) > > > > #else > > > > #define INET_ATON(s, a) ((a.s_addr =3D inet_addr(s)) =3D=3D I= NADDR_NONE) > > #define SOCKLEN int > > #define SOCKETERRORMSG get_WSA_error_str(WSAGetLastError()) > > #define CLOSESOCKET(s) closesocket(s) > > > > #define THREAD HANDLE > > #define THREADIDDECL(t) unsigned t; > > #define THREADCREATE(func, args, thread, id) \ > > (thread =3D (HANDLE)_beginthreadex(NULL, 0, func, (PV= OID)args, 0, &id)) > > #define THREADCREATE_ERROR NULL > > #define THREADFUNCDECL(func) unsigned __stdcall func(PVOID ar= gs) > > #define THREADFUNCRET(r) int r =3D 0 > > #define THREADJOIN(t) WaitForSingleObject(t, INFINITE) > > #define MUTEX CRITICAL_SECTION > > #define MUTEXINIT(m) InitializeCriticalSection(m) > > #define MUTEXLOCK(m) EnterCriticalSection(m) > > #define MUTEXUNLOCK(m) LeaveCriticalSection(m) > > #define MUTEXDESTROY(m) DeleteCriticalSection(m) > > > > #endif > > > > > Sorry my English :) > > > > Your English is fine, no apology needed! > > > > Thanks for joining the mailing list and helping! > > > > -SteveK > > > > -- > > Steve Kann - Chief Engineer - 520 8th Ave #2300 NY 10018 - (212) 5= 33-1775 > > HorizonLive.com - collaborate . interact . learn > > "The box said 'Requires Windows 95, NT, or better,' so I installed= Linux." > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Etnus, makers of TotalView, The de= bugger > > for complex code. Debugging C/C++ programs can leave you feeling lost= and > > disoriented. TotalView can help you find your way. Available on major= UNIX > > and Linux platforms. Try it free. www.etnus.com > > _______________________________________________ > > Iaxclient-devel mailing list > > Iax...@li... > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >=20 > -- > -------------------------------------------------------------- > 12:03am up 356 days, 6 users, load average: 0.68, 0.43, 0.30 > 89 processes: 88 sleeping, 1 running, 0 zombie, 0 stopped > CPU states: 1.2% user, 1.2% system, 0.0% nice, 97.4% idle > Mem: 257620K av, 130248K used, 127372K free, 56024K shrd > Swap: 401584K av, 280K used, 401304K free 52548K cached >=20 >=20 --=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." |
|
From: The S. <kc...@al...> - 2003-03-06 12:24:19
|
Steve Kann wrote: > KC, > > There's several versions of things going around here, that > people are talking about, most of which are referenced at > http://iaxclient.sourceforge.net/ > > Andre's work is the IAXPHONE stuff, listed there, but he's still workin= g > on that port. There's a snapshot that i've mirrored on the iaxclient > webpage. Hi Steve and all, I Allready cheked out youre SF-page ... . But if anybody is having new (= better) code even for testing should'nt it be in a cvs then ?? And later on it could move to * ?? is this an Idea ? Greetings KC > > > There is the Digium CVS, which has a kindof outdated and hacky Win32 > "winiphone", which is really just a proof-of-concept kind of thing. > > Then, there's this new code we're trying to develop, which doesn't yet > have any releases. > > -SteveK > > On Wed, Mar 05, 2003 at 01:40:02AM +0100, The Sysop wrote: > > Hi everybody, > > > > I use bcb 6 to compile an new version of IAX lib from cvs .. This is = working but seems to have here and there some quarks .. ( at the > > moment i am struckling with (un) authenticated calls) > > > > My question now is .. are these problems applying to this version of = the iax lib as well ?? Or do you guys use an different cvs or > > versions that are outside digium cvs ?? > > > > As far as I can see This version I just resently obtained doesn't use= direct X, but native Api calls .. and to my first impression if > > I call my win32 iax client .. it sounds resenable .. > > > > Greetings KC > > > > > > Steve Kann wrote: > > > > > Thanks for writing back Andre! > > > > > > On Tue, Mar 04, 2003 at 04:49:59AM +0100, Andre Bierwirth wrote: > > > > Hi Steve, i use the lcc Win32 Compiler for by C Source. I had als= o memory of problems in my first nonreleased Versions. There was > > > > some Problems with freeing of iax_frames but i=B4m not sure. It=B4= s long time ago. > > > > > > > > My Sound Output is currently in Delphi GUI because i have never > > > > Programmed C before this. It was only to try the DirectX API for > > > > Output. (This was my first App with DirectX). Now i know enough a= bout > > > > C to write the Soundoutput directly in C like an Phonecore(GNOPho= ne) > > > > modul. > > > > > > Thanks, that's what I expected, and remember from when I looked at = your > > > sources. > > > > > > > The bad Quality comes from my hardcoded Buffersize. On some Compu= ters > > > > i fix this Problem with a recompile and a bigger Outputbuffer. T= here > > > > a big problems too on Win32 and DirectX. On the Snomphone you hav= e > > > > nearly zero latency for the Sound Output. On DirectX i have to fi= ll a > > > > Ringbuffer with the Audiodata. And there i have my bigest Problem= s the > > > > Thread timing on Win32 is terrible. If i have a Ringbuffer with 2 > > > > 160byte Chunks, i have many buffer underruns if i minimize and > > > > maximize any Windows. I see currently no Soundapplications with a > > > > smaller Latency than 50ms and DirectX, because the Threading on > > > > Windows makes it impossible. I have try an Thread Priotity Realti= me > > > > but i have still always bufferunderuns if i minimize or maximize = some > > > > Windows. I think Microsoft=B4s Window animation have a higher pri= ority > > > > as a Realtime Application. With a higher Latency and a bigger Bu= ffer > > > > i have no Problems with the Audio quality. > > > > > > Interesting. > > > > > > I think that, in our application, this should be something that is > > > tunable at runtime, or at least compile time. > > > > > > For our application, we'd happily bump up the latency by another 50= ms or > > > 100ms, if it meant really good quality. > > > > > > Since I expect that many users will be using internet connections f= or > > > this, there's going to be several sources of latency in the whole > > > system: > > > > > > 1) Actual network transmission time: Somewhere from 2 - 2000 ms. > > > 2) The clients' Jitter buffer. > > > 3) The clients audio device buffer. > > > > > > Something we might want to look at later is to see if or how we can > > > "combine" 2 and 3? > > > > > > As far as audio driver technologies, I don't know what benefits Dir= ectX > > > has over the "standard" windows audio interfaces, but we'll need to > > > support "out-of-the-box" Windows installations without needing them= to > > > go and download and install DirectX, so we'll need to support the > > > standard windows APIs as a baseline. Then, if there's benefits to = it, > > > we could detect the presence of compatible DirectX interfaces, and = use > > > them, if the user already has them installed. > > > > > > > I think the your Library need some Abstraction Parts for Threads = and > > > > Thread Syncronisation. It is not very difficult to Implement a PT= hread > > > > for Win32. Same with Mutexes. I didn=B4t know anything about Mac,= so i > > > > can talk only about my Win32 Problems. > > > > > > First, Mac OS X is really very much like FreeBSD, except, in our ca= se, > > > for Audio stuff, and GUI stuff. So, it fully supports pthreads. > > > > > > For Windows, it's my understanding that their threads and "critical > > > sections" are pretty similar to pthreads and mutexes. For another > > > project, we just do some #defines to make them act the same way, li= ke > > > this: > > > > > > #ifndef _WIN32 > > > > > > #define SOCKET int > > > #define INVALID_SOCKET -1 > > > #define SOCKET_ERROR -1 > > > #define SD_SEND 1 > > > > > > #define INET_ATON(s, a) (inet_aton(s, &a) =3D=3D 0) > > > #define SOCKLEN socklen_t > > > #define SOCKETERRORMSG strerror(errno) > > > #define CLOSESOCKET(s) close(s) > > > > > > #define THREAD pthread_t > > > #define THREADIDDECL(t) > > > #define THREADCREATE(func, args, thread, id) \ > > > pthread_create(&thread, NULL, func, args) > > > #define THREADCREATE_ERROR -1 > > > #define THREADFUNCDECL(func) void * func(void *args) > > > #define THREADFUNCRET(r) void * r > > > #define THREADJOIN(t) pthread_join(t, 0) > > > #define MUTEX pthread_mutex_t > > > #define MUTEXINIT(m) pthread_mutex_init(m, NULL) //TODO: ch= eck error > > > #define MUTEXLOCK(m) pthread_mutex_lock(m) > > > #define MUTEXUNLOCK(m) pthread_mutex_unlock(m) > > > #define MUTEXDESTROY(m) pthread_mutex_destroy(m) > > > > > > #else > > > > > > #define INET_ATON(s, a) ((a.s_addr =3D inet_addr(s)) =3D=3D= INADDR_NONE) > > > #define SOCKLEN int > > > #define SOCKETERRORMSG get_WSA_error_str(WSAGetLastError()) > > > #define CLOSESOCKET(s) closesocket(s) > > > > > > #define THREAD HANDLE > > > #define THREADIDDECL(t) unsigned t; > > > #define THREADCREATE(func, args, thread, id) \ > > > (thread =3D (HANDLE)_beginthreadex(NULL, 0, func, (= PVOID)args, 0, &id)) > > > #define THREADCREATE_ERROR NULL > > > #define THREADFUNCDECL(func) unsigned __stdcall func(PVOID = args) > > > #define THREADFUNCRET(r) int r =3D 0 > > > #define THREADJOIN(t) WaitForSingleObject(t, INFINITE) > > > #define MUTEX CRITICAL_SECTION > > > #define MUTEXINIT(m) InitializeCriticalSection(m) > > > #define MUTEXLOCK(m) EnterCriticalSection(m) > > > #define MUTEXUNLOCK(m) LeaveCriticalSection(m) > > > #define MUTEXDESTROY(m) DeleteCriticalSection(m) > > > > > > #endif > > > > > > > Sorry my English :) > > > > > > Your English is fine, no apology needed! > > > > > > Thanks for joining the mailing list and helping! > > > > > > -SteveK > > > > > > -- > > > Steve Kann - Chief Engineer - 520 8th Ave #2300 NY 10018 - (212)= 533-1775 > > > HorizonLive.com - collaborate . interact . learn > > > "The box said 'Requires Windows 95, NT, or better,' so I install= ed Linux." > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Etnus, makers of TotalView, The = debugger > > > for complex code. Debugging C/C++ programs can leave you feeling lo= st and > > > disoriented. TotalView can help you find your way. Available on maj= or UNIX > > > and Linux platforms. Try it free. www.etnus.com > > > _______________________________________________ > > > Iaxclient-devel mailing list > > > Iax...@li... > > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > -- > > -------------------------------------------------------------- > > 12:03am up 356 days, 6 users, load average: 0.68, 0.43, 0.30 > > 89 processes: 88 sleeping, 1 running, 0 zombie, 0 stopped > > CPU states: 1.2% user, 1.2% system, 0.0% nice, 97.4% idle > > Mem: 257620K av, 130248K used, 127372K free, 56024K shrd > > Swap: 401584K av, 280K used, 401304K free 52548K cached > > > > > > -- > Steve Kann - Chief Engineer - 520 8th Ave #2300 NY 10018 - (212) 533= -1775 > HorizonLive.com - collaborate . interact . learn > "The box said 'Requires Windows 95, NT, or better,' so I installed L= inux." > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debu= gger > for complex code. Debugging C/C++ programs can leave you feeling lost a= nd > disoriented. TotalView can help you find your way. Available on major U= NIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel -- -------------------------------------------------------------- 12:03am up 356 days, 6 users, load average: 0.68, 0.43, 0.30 89 processes: 88 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 1.2% user, 1.2% system, 0.0% nice, 97.4% idle Mem: 257620K av, 130248K used, 127372K free, 56024K shrd Swap: 401584K av, 280K used, 401304K free 52548K cached |
|
From: Steve K. <st...@St...> - 2003-03-06 15:17:33
|
On Thu, Mar 06, 2003 at 01:29:03PM +0100, The Sysop wrote: > Steve Kann wrote: > > > KC, > > > > There's several versions of things going around here, that > > people are talking about, most of which are referenced at > > http://iaxclient.sourceforge.net/ > > > > Andre's work is the IAXPHONE stuff, listed there, but he's still working > > on that port. There's a snapshot that i've mirrored on the iaxclient > > webpage. > > Hi Steve and all, > > I Allready cheked out youre SF-page ... . But if anybody is having new (better) code even for testing should'nt it be in a cvs then ?? > And later on it could move to * ?? We should have something in CVS soon. We're changing the structure around a bit, and it would be messy to do that in CVS. As far as putting it on Digium's site, that's up to Mark, not us. -SteveK -- Steve Kann - Chief Engineer - 520 8th Ave #2300 NY 10018 - (212) 533-1775 HorizonLive.com - collaborate . interact . learn "The box said 'Requires Windows 95, NT, or better,' so I installed Linux." |
|
From: Steve K. <st...@st...> - 2003-06-09 23:51:29
|
Hey kc, Have you had a chance to see what we've done with iaxclient lately? We have working clients on all three platforms now. (plenty of work left to do, though!). On Tue, 2003-03-04 at 19:40, The Sysop wrote: > Hi everybody, > > I use bcb 6 to compile an new version of IAX lib from cvs .. This is > working but seems to have here and there some quarks .. ( at the > moment i am struckling with (un) authenticated calls) > > My question now is .. are these problems applying to this version of > the iax lib as well ?? Or do you guys use an different cvs or versions > that are outside digium cvs ?? > > As far as I can see This version I just resently obtained doesn't use > direct X, but native Api calls .. and to my first impression if I call > my win32 iax client .. it sounds resenable .. > > Greetings KC > > > Steve Kann wrote: > > > Thanks for writing back Andre! > > > > On Tue, Mar 04, 2003 at 04:49:59AM +0100, Andre Bierwirth wrote: > > > 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´m not sure. It´s > > long time ago. > > > > > > My Sound Output is currently in Delphi GUI because i have never > > > Programmed 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 to write the Soundoutput directly in C like an > > Phonecore(GNOPhone) > > > modul. > > > > Thanks, that's what I expected, and remember from when I looked at > > your > > sources. > > > > > The bad Quality comes from my hardcoded Buffersize. On some > > Computers > > > i fix 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 Problems > > the > > > Thread timing on Win32 is terrible. If i have a Ringbuffer with 2 > > > 160byte Chunks, i have many buffer underruns if i minimize and > > > maximize any Windows. I see currently no Soundapplications with a > > > smaller Latency than 50ms and DirectX, because the Threading on > > > Windows makes it impossible. I have try an Thread Priotity > > Realtime > > > but i have still always bufferunderuns if i minimize or maximize > > some > > > Windows. I think Microsoft´s Window animation have a higher > > priority > > > as a Realtime Application. With a higher Latency and a bigger > > Buffer > > > i have no Problems with the Audio quality. > > > > Interesting. > > > > I think that, in our application, this should be something that is > > tunable at runtime, or at least compile time. > > > > For our application, we'd happily bump up the latency by another > > 50ms or > > 100ms, if it meant really good quality. > > > > Since I expect that many users will be using internet connections > > for > > this, there's going to be several sources of latency in the whole > > system: > > > > 1) Actual network transmission time: Somewhere from 2 - 2000 ms. > > 2) The clients' Jitter buffer. > > 3) The clients audio device buffer. > > > > Something we might want to look at later is to see if or how we can > > "combine" 2 and 3? > > > > As far as audio driver technologies, I don't know what benefits > > DirectX > > has over the "standard" windows audio interfaces, but we'll need to > > support "out-of-the-box" Windows installations without needing them > > to > > go and download and install DirectX, so we'll need to support the > > standard windows APIs as a baseline. Then, if there's benefits to > > it, > > we could detect the presence of compatible DirectX interfaces, and > > use > > them, if the user already has them installed. > > > > > I think the your Library need some Abstraction Parts for Threads > > and > > > Thread Syncronisation. It is not very difficult to Implement a > > PThread > > > for Win32. Same with Mutexes. I didn´t know anything about Mac, so > > i > > > can talk only about my Win32 Problems. > > > > First, Mac OS X is really very much like FreeBSD, except, in our > > case, > > for Audio stuff, and GUI stuff. So, it fully supports pthreads. > > > > For Windows, it's my understanding that their threads and "critical > > sections" are pretty similar to pthreads and mutexes. For another > > project, we just do some #defines to make them act the same way, > > like > > this: > > > > #ifndef _WIN32 > > > > #define SOCKET int > > #define INVALID_SOCKET -1 > > #define SOCKET_ERROR -1 > > #define SD_SEND 1 > > > > #define INET_ATON(s, a) (inet_aton(s, &a) == 0) > > #define SOCKLEN socklen_t > > #define SOCKETERRORMSG strerror(errno) > > #define CLOSESOCKET(s) close(s) > > > > #define THREAD pthread_t > > #define THREADIDDECL(t) > > #define THREADCREATE(func, args, thread, id) \ > > pthread_create(&thread, NULL, func, args) > > #define THREADCREATE_ERROR -1 > > #define THREADFUNCDECL(func) void * func(void *args) > > #define THREADFUNCRET(r) void * r > > #define THREADJOIN(t) pthread_join(t, 0) > > #define MUTEX pthread_mutex_t > > #define MUTEXINIT(m) pthread_mutex_init(m, NULL) //TODO: > > check error > > #define MUTEXLOCK(m) pthread_mutex_lock(m) > > #define MUTEXUNLOCK(m) pthread_mutex_unlock(m) > > #define MUTEXDESTROY(m) pthread_mutex_destroy(m) > > > > #else > > > > #define INET_ATON(s, a) ((a.s_addr = inet_addr(s)) == > > INADDR_NONE) > > #define SOCKLEN int > > #define SOCKETERRORMSG get_WSA_error_str(WSAGetLastError()) > > #define CLOSESOCKET(s) closesocket(s) > > > > #define THREAD HANDLE > > #define THREADIDDECL(t) unsigned t; > > #define THREADCREATE(func, args, thread, id) \ > > (thread = (HANDLE)_beginthreadex(NULL, 0, func, > > (PVOID)args, 0, &id)) > > #define THREADCREATE_ERROR NULL > > #define THREADFUNCDECL(func) unsigned __stdcall func(PVOID > > args) > > #define THREADFUNCRET(r) int r = 0 > > #define THREADJOIN(t) WaitForSingleObject(t, INFINITE) > > #define MUTEX CRITICAL_SECTION > > #define MUTEXINIT(m) InitializeCriticalSection(m) > > #define MUTEXLOCK(m) EnterCriticalSection(m) > > #define MUTEXUNLOCK(m) LeaveCriticalSection(m) > > #define MUTEXDESTROY(m) DeleteCriticalSection(m) > > > > #endif > > > > > Sorry my English :) > > > > Your English is fine, no apology needed! > > > > Thanks for joining the mailing list and helping! > > > > -SteveK > > > > -- > > Steve Kann - Chief Engineer - 520 8th Ave #2300 NY 10018 - (212) > > 533-1775 > > HorizonLive.com - collaborate . interact . learn > > "The box said 'Requires Windows 95, NT, or better,' so I > > installed Linux." > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Etnus, makers of TotalView, The > > debugger > > for complex code. Debugging C/C++ programs can leave you feeling > > lost and > > disoriented. TotalView can help you find your way. Available on > > major UNIX > > and Linux platforms. Try it free. www.etnus.com > > _______________________________________________ > > Iaxclient-devel mailing list > > Iax...@li... > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > -- > -------------------------------------------------------------- > 12:03am up 356 days, 6 users, load average: 0.68, 0.43, 0.30 > 89 processes: 88 sleeping, 1 running, 0 zombie, 0 stopped > CPU states: 1.2% user, 1.2% system, 0.0% nice, 97.4% idle > Mem: 257620K av, 130248K used, 127372K free, 56024K shrd > Swap: 401584K av, 280K used, 401304K free 52548K cached > > -- Steve Kann - Chief Engineer - 520 8th Ave #2300 NY 10018 - (212) 533-1775 HorizonLive.com - collaborate . interact . learn "The box said 'Requires Windows 95, NT, or better,' so I installed Linux." |
|
From: Andre B. <ast...@km...> - 2003-03-04 03:50:10
|
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
|
|
From: Steve K. <st...@St...> - 2003-03-04 14:46:04
|
Thanks for writing back Andre!
On Tue, Mar 04, 2003 at 04:49:59AM +0100, Andre Bierwirth wrote:
> Hi Steve, i use the lcc Win32 Compiler for by C Source. I had also memo=
ry of problems in my first nonreleased Versions. There was
> some Problems with freeing of iax_frames but i=B4m not sure. It=B4s lon=
g time ago.
>=20
> My Sound Output is currently in Delphi GUI because i have never
> Programmed 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 to write the Soundoutput directly in C like an Phonecore(GNOPhone)
> modul.
Thanks, that's what I expected, and remember from when I looked at your
sources.
> The bad Quality comes from my hardcoded Buffersize. On some Computers
> i fix 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 Problems the
> Thread timing on Win32 is terrible. If i have a Ringbuffer with 2
> 160byte Chunks, i have many buffer underruns if i minimize and
> maximize any Windows. I see currently no Soundapplications with a
> smaller Latency than 50ms and DirectX, because the Threading on
> Windows makes it impossible. I have try an Thread Priotity Realtime
> but i have still always bufferunderuns if i minimize 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 Audio quality.
Interesting. =20
I think that, in our application, this should be something that is
tunable at runtime, or at least compile time. =20
For our application, we'd happily bump up the latency by another 50ms or
100ms, if it meant really good quality. =20
Since I expect that many users will be using internet connections for
this, there's going to be several sources of latency in the whole
system:
1) Actual network transmission time: Somewhere from 2 - 2000 ms.
2) The clients' Jitter buffer.
3) The clients audio device buffer.
Something we might want to look at later is to see if or how we can
"combine" 2 and 3?
As far as audio driver technologies, I don't know what benefits DirectX
has over the "standard" windows audio interfaces, but we'll need to
support "out-of-the-box" Windows installations without needing them to
go and download and install DirectX, so we'll need to support the
standard windows APIs as a baseline. Then, if there's benefits to it,
we could detect the presence of compatible DirectX interfaces, and use
them, if the user already has them installed.
> I think the your Library need some Abstraction Parts for Threads and
> Thread 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.
First, Mac OS X is really very much like FreeBSD, except, in our case,
for Audio stuff, and GUI stuff. So, it fully supports pthreads.
For Windows, it's my understanding that their threads and "critical
sections" are pretty similar to pthreads and mutexes. For another
project, we just do some #defines to make them act the same way, like
this:
#ifndef _WIN32
#define SOCKET int
#define INVALID_SOCKET -1
#define SOCKET_ERROR -1
#define SD_SEND 1
#define INET_ATON(s, a) (inet_aton(s, &a) =3D=3D 0)
#define SOCKLEN socklen_t
#define SOCKETERRORMSG strerror(errno)
#define CLOSESOCKET(s) close(s)
#define THREAD pthread_t
#define THREADIDDECL(t)
#define THREADCREATE(func, args, thread, id) \
pthread_create(&thread, NULL, func, args)
#define THREADCREATE_ERROR -1
#define THREADFUNCDECL(func) void * func(void *args)
#define THREADFUNCRET(r) void * r
#define THREADJOIN(t) pthread_join(t, 0)
#define MUTEX pthread_mutex_t
#define MUTEXINIT(m) pthread_mutex_init(m, NULL) //TODO: check error
#define MUTEXLOCK(m) pthread_mutex_lock(m)
#define MUTEXUNLOCK(m) pthread_mutex_unlock(m)
#define MUTEXDESTROY(m) pthread_mutex_destroy(m)
#else
#define INET_ATON(s, a) ((a.s_addr =3D inet_addr(s)) =3D=3D INADDR_NONE)
#define SOCKLEN int
#define SOCKETERRORMSG get_WSA_error_str(WSAGetLastError())
#define CLOSESOCKET(s) closesocket(s)
#define THREAD HANDLE
#define THREADIDDECL(t) unsigned t;
#define THREADCREATE(func, args, thread, id) \
(thread =3D (HANDLE)_beginthreadex(NULL, 0, func, (PVOID)args, 0, &id))
#define THREADCREATE_ERROR NULL
#define THREADFUNCDECL(func) unsigned __stdcall func(PVOID args)
#define THREADFUNCRET(r) int r =3D 0
#define THREADJOIN(t) WaitForSingleObject(t, INFINITE)
#define MUTEX CRITICAL_SECTION
#define MUTEXINIT(m) InitializeCriticalSection(m)
#define MUTEXLOCK(m) EnterCriticalSection(m)
#define MUTEXUNLOCK(m) LeaveCriticalSection(m)
#define MUTEXDESTROY(m) DeleteCriticalSection(m)
#endif
> Sorry my English :)
Your English is fine, no apology needed!
Thanks for joining the mailing list and helping! =20
-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."
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X