choice of thread API for audio feeder purposes
choice of thread API for audio feeder purposes
- Subject: choice of thread API for audio feeder purposes
- From: Kurt Bigler <email@hidden>
- Date: Wed, 26 Mar 2003 16:58:26 -0800
What is the simplest thread API that provides the functionality needed to
implement audio feeder threads? It would be good to have a separate answer
for Objective-C and non-Objective-C based projects. Any information about
advantages or problems with particular apis would be helpful.
I'm sure I could dig some more, but I figure this is a good question that
will benefit others.
I see from postings to this list that some people are using pthreads, and
then using other lower-level mach thread apis to do things like setting
thread priority, etc. But then why not just use the lower-level api in the
first place? (But I have not found it yet.)
I have seen NSThreads, for example in Kurt Revis's PlayBufferedSoundFile
project, but for the moment want to avoid introducing Objective-C into my
project just in order to create threads.
I have heard of something called cthreads, but don't know if they are around
any more.
Thanks for any advice.
-Kurt Bigler
DOCUMENTATION P.S.: I have been wading through the developer.apple.com
documentation, and have found it pretty difficult to even find out what the
available thread api's are, though I have found lots of things about kernel
threads, some mention of pthreads (but not the API). I certainly do find it
to be a struggle to wrest information from the developer website, and I
guess I haven't found a strategy for finding documentation that really
works. "Works" would mean having a way to find relevant apis given a
desired area of functionality in 30 minutes or less. It should also be
noted that nowhere in the online documentation have I seen the man pages
even mentioned! Twice lately I have gotten reminders to look in the man
pages (which are all too familiar to me from other contexts) and I was quite
surprised.
It may be that the multifarous history behind OS X precludes a totally
integrated approach to documentation in the forseeable future, or perhaps
_ever_ with Darwin being sort of a separate effort. However, I think it
might be possible to create an integrated overview that is rich in pointers
to other sources of information. There are some attempts at this,
apparently, but I don't think anyone has actually approached it from the
stand point of organization by functionality. This is simialar to a FAQ
approach. If the man pages _must_ be consulted then ideally they are all
available online, and can be linked to as web pages.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.