Re: Audio processing thread realtime priorties
Re: Audio processing thread realtime priorties
- Subject: Re: Audio processing thread realtime priorties
- From: William Stewart <email@hidden>
- Date: Thu, 11 Jun 2009 14:54:35 -0700
Hi Wolfgang
I wouldn't change the priority of the IOProc callback's thread - this
is already set at a priority that is realtime and changing this would
be a bad idea.
It doesn't sound to me that the problem is one of priority - the
overload is generated by the HAL at the end of any given IOProc
callback - it looks at the time you have come back and if you are
late, generates the overload. So, I'd examine why you are later -
perhaps you have unbounded wait states, sleeps or some other
operations in the IOProc that is causing you to yield time?
Bill
On Jun 10, 2009, at 12:43 PM, Wolfgang Kundrus wrote:
Hi Jeff,
thanks for the explanation. That definitely helps.
We are writing a DAW. Our mix engine currently runs in the IOProc
callback of the Coreaudio device. That works, but not as reliable as
I want it to. The audio device keeps reporting overloads at higher
loads and it looks like the callback gets interupted. I attempted to
improve that, by adjusting the thread priorities in the way I
described it, but the result was not good enough yet.
That might be not the right way to do it on the Mac, so I consider
to spawn a separate thread for the mix engine now, that gets its
wakeup signal from the IOProc callback.
All the best
Wolfgang
> > 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
_______________________________________________
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