CLI producer code cycle starvation
CLI producer code cycle starvation
- Subject: CLI producer code cycle starvation
- From: Jim Snyder <email@hidden>
- Date: Thu, 20 Jun 2002 10:41:31 -0400
I've ported an audio decompression program (audio player) to Darwin/CLI.
It's pure posix C. The audio output code was extracted from the daisy
example program in the Developer tree. The objects are linked against
the cc default libraries and
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
The binary is a Mach-O executable.
(Because this is a program which compiles and links on several architectures
from a common source tree, I'm using raw command line makefiles and gcc,
if that's relevant to anything.)
The decompression code alone takes about 4% of the processor, a 450MHz
g3 on a Sonnet PCI upgrade card, 1MBy cache, about 45MHz memory bus speed.
The player program follows standard lines: the decompression code reads a
data frame, decompresses it, writes to a ring buffer, and usleeps should the
ring buffer become full; the consumer code is an IOProc which does nothing
but read from the ring buffer and adjust buffer indices. ie very asymmetrical
CPU load. The decompressor is too heavyweight to put into the IOProc, IMHO.
When I run the audio player from the command line, leaving the rest of
the system quiescent, the audio file plays to completion. But if I grab
a window on the screen with the mouse, and wave the window about vigorously,
the IOProc empties the ring buffer before the decompressor gets scheduled
again, based on diagnostic printout of buffer indices and the like.
At the extreme, I've made the ring buffer 23 secs long (1024 frames), but
once I start waving the window, after 23 secs the IOProc chokes because
the ring buffer is empty.
That is: my audio IOProc empties the ring buffer for 23 seconds during
which time the producer code is scheduled to run at most once, and on most
invocations not at all.
This occurs even with:
# nice -20 player file
The error diagnostics suggest that "nice" has not affected the scheduling
of the producer code at all.
I've grubbed around in the archives a bit, and gather that lots of people
have had this sort of problem, but I haven't stumbled over a suggestion
which spells out what one does in, perhaps because most of the people
on this list know a lot more about osx than I do, so that hints are all
that are needed.
I gather from the archives that the IOProc is a rt thread. The decompression
code, absent the audio code, is unthreaded, so there are no explicit threads
whose priority can be adjusted to give the producer process more cycles.
At the risk of exposing my ignorance,
a) is there a pointer to recommended literature which deals with this sort of
problem in the osx environment;
b) what's the recommended way of getting the producer code scheduled;
c) just for my curiousity, why is the scheduler (almost) *never* scheduling
the producer process? Is it because the program itself is scheduled every
time there's a call to the audio IOProc, and so by the scheduler's lights,
the player is getting its share of cycles?
Apologies for being verbose.
Thanks, Jim Snyder
_______________________________________________
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.