Re: [coreaudio] Re: Latest Documentation?
Re: [coreaudio] Re: Latest Documentation?
- Subject: Re: [coreaudio] Re: Latest Documentation?
- From: robert <email@hidden>
- Date: Fri, 15 Feb 2002 08:43:53 +0100
- Mail-followup-to: email@hidden
>
All I want is for Darwin to match Linux in this regard -- in Linux:
>
>
man sched_setscheduler
>
man mlock
>
>
is a good start, these FAQs:
>
>
http://www.linuxdj.com/audio/lad/resources.php3
>
>
tell how audio programmers should use these Linux scheduling and memory
>
APIs in real applications, and for those who need more background
>
material, the O'Reilly book referenced in the sched_setscheduler man page
>
tells the complete story of the POSIX real-time APIs and how to use them.
I wonder if using real-time extensions is really necessary to be able to do
what CoreAudio does. I mean, afaik, CoreAudio can already handle a whole
lot without having to resort to real-time scheduling/queues, and it might
be worthwhile to investigate bottlenecks without having to resort to using
'esoteric' extensions.
One document which I have read about this, and which might concur with
this, is:
http://mambo.peabody.jhu.edu/~karlmac/publications/latency-icmc2001.pdf
(also mentioned on the url you mention above). This document shows that
stock OSX (an 'old' version even, judging from the document) has lower
latency _under heavy loads_ than a patched Linux.
I figure this is because the CoreAudio developers have, afaik, focussed
primarily on achieving low latency by optimising kernel/userspace
transitions and using AltiVec for what its good in, instead of resorting to
RT patches or even rt-queues (which I think wouldn't be hard to port from
FreeBSD, and which might already result to even lower latency).
Btw, mlock() is available in Darwin :)
robert
_______________________________________________
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.