Re: CLI producer code cycle starvation
Re: CLI producer code cycle starvation
- Subject: Re: CLI producer code cycle starvation
- From: Jim Snyder <email@hidden>
- Date: Thu, 20 Jun 2002 12:23:24 -0400
Much obliged to you (and to Kurt Revis, who also responded).
|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.
Well, as a practical matter, it's not a robust app the way
it is now. There are a lot more machines running 10.0 and
10.1 than Jaguar today. I suppose the process could check
the OS version and manipulate process priority only if it
finds itself running on 10.[01].
|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).
There's one point here which is still unclear to me (thru
sheer ignorance of osx internals). You say that every Mach
process consists of one or more threads. I've been accustomed
to seeing threads spawned explicitly.
Does this implicit threading of processes mean that there's
no other setup code involved? You just act as though your
main process has been spawned as a thread for you, and
issue whatever thread calls you need to manipulate your
thread?
|the following snippet will set the scheduling priority
|of the thread that runs it to time-constraint. it
Great, thanks!
|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
|> ...
|> 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.
|> ...
|> 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?
_______________________________________________
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.