Re: Audio processing thread realtime priorties
Re: Audio processing thread realtime priorties
- Subject: Re: Audio processing thread realtime priorties
- From: Jeff Moore <email@hidden>
- Date: Tue, 09 Jun 2009 09:33:01 -0700
On Jun 9, 2009, at 3:43 AM, Wolfgang Kundrus wrote:
I have had mixed results with the recommended way of setting up
realtime priorities for the audio processing thread in our
application. I am using thread_policy_set to setup
THREAD_TIME_CONSTRAINT_POLICY. I have tried to read every bit of
information about this and I am still confused about the values in
the thread_time_constraint_policy data structure.
I have tried to do a good job in calculating them based on the
buffersize of the IOProc. Unfortunatly, that did not give good
results at 2048 samples and beyond, we are experiencing more drop
outs. It had to set the values to fixed numbers in order to get the
same performance at larger blocksize. So, my questions are:
1) Are the values in thread_time_constraint_policy_data_t used by
the scheduler and in which way ?
Absolutely. All four values are vital to configure your thread properly.
2) Why would be a period of 1ms produce better results at wakeup
rates of 50 ms ?
It's pretty much impossible to answer this question without knowing
more about what you are doing than what you have stated here.
3) What excactly does the constraint value mean ? In most code
examples it is simply the same as period.
Here's a rundown on the four fields in the
thread_time_constraint_policy_data_t struct:
period: The nominal amount of time between duty cycles.
computation: The amount of time at the beginning of a new duty cycle
when the thread is not pre-emptible by other time constraint threads.
After this amount of time has gone by, the scheduler will run a timer
with a period of this amount of time. Each time the timer goes off,
the scheduler will re-evaluate whether or not to pre-empt the thread.
Note that setting this value too small can result in a lot of extra
overhead on the scheduler's behalf due to the timer interrupt going
off all the time.
constraint: The nominal amount of time the duty cycle of the thread
will take. Note that if your thread runs for longer than this time,
the scheduler will penalize the thread by pre-empting it and reducing
it's priority a great deal. The scheduler is very harsh (and right to
be so, IMHO) to time constraint that blows out it's constraints.
preemptible: Whether or not the thread is pre-emptible by other time
constraint threads. This should pretty much always be true for any app-
owned threads. I can't think of a single instance where setting this
to false would be a good idea for an application.
At any rate, it's pretty hard to help you out here without knowing
more about your threading situation. In a lot of cases, you don't need
even need a time constraint thread. It all depends on what you are
doing and how you are doing it.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden