• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
choice of thread API for audio feeder purposes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

  • Follow-Ups:
    • Re: choice of thread API for audio feeder purposes
      • From: Garth Cummings <email@hidden>
    • Re: choice of thread API for audio feeder purposes
      • From: Kurt Revis <email@hidden>
    • Re: choice of thread API for audio feeder purposes
      • From: Andrew Kimpton <email@hidden>
  • Prev by Date: Re: Stream format
  • Next by Date: Re: choice of thread API for audio feeder purposes
  • Previous by thread: Debugging Malloc problems
  • Next by thread: Re: choice of thread API for audio feeder purposes
  • Index(es):
    • Date
    • Thread