Re: CLI producer code cycle starvation
Re: CLI producer code cycle starvation
- Subject: Re: CLI producer code cycle starvation
- From: "Michael C. Thornburgh" <email@hidden>
- Date: Thu, 20 Jun 2002 08:50:49 -0700 (PDT)
your producer thread never gets any CPU time because
the Window Server's Mach priority is way too high.
i believe that your application is a legitimate use
of real-time (aka time constraint) scheduling, since
your producer thread must run for a little while periodically
in order to not have your buffer run dry. others on
this list may disagree, because of the dangers of making
a real-time thread, and because of upcoming changes
in Jaguar to the priority of the Window Server.
every Mach task (process) has at least one thread. your
program will have two threads (the IOProc runs in a real-time
thread associated with the audio device, and then there's
your main thread where your producer code ends up
running).
the following snippet will set the scheduling priority
of the thread that runs it to time-constraint. it
says "every 10ms, i need 1ms of CPU time, and if i
use more than 5ms in that 10, or if someone else really
needs to run, that's OK too." you should adjust the settings
to meet your needs, and put it in your producer thread
right before you go into your "while (data) { decompress(); }"
loop.
#include <mach/thread_policy.h>
#include <mach/thread_act.h>
#include <mach/mach_init.h>
....
struct thread_time_constraint_policy constraintPolicy;
kern_return_t rv;
Float64 clockFrequency = AudioGetHostClockFrequency();
constraintPolicy.period = 0.010 * clockFrequency; // 10ms
constraintPolicy.computation = 0.001 * clockFrequency; // 1ms
constraintPolicy.constraint = 0.005 * clockFrequency; // 5ms
constraintPolicy.preemptible = true;
rv = thread_policy_set ( mach_thread_self(),
THREAD_TIME_CONSTRAINT_POLICY,
(thread_policy_t) &constraintPolicy,
THREAD_TIME_CONSTRAINT_POLICY_COUNT );
-mike
>
From: Jim Snyder <email@hidden>
>
To: email@hidden
>
Subject: CLI producer code cycle starvation
>
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.