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: Thu, 11 Jun 2009 14:53:55 -0700
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.
Overloads are basically the HAL's way of telling you that you are
doing too much work in your IOProc.
I attempted to improve that, by adjusting the thread priorities in
the way I described it, but the result was not good enough yet.
I don't follow this. It sounds like you are saying that you are trying
to fix this problem by adjusting the scheduling parameters of the
HAL's IO thread. I can't stress enough how much of a bad thing that
is. Not to mention, it won't fix the problem (which you have already
surmised it seems).
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.
At the core of your problem is that you are trying to do too much work
on the IO thread such that you are then missing the real-time
deadlines. This is what is probably what is causing your overloads.
The only way to address this is going to involve doing less work on
the IO thread, so offloading the work to a worker thread is a fine idea.
The catch is going to be managing the worker thread and it's
communication with the IO thread. This will be non-trivial given the
constraints about what you can and can't do on the IO thread (no
blocking, no memory allocation, etc.).
That said, using a worker thread might not help either. This doesn't
magically make the deadline softer or give you any more time to do the
work. You will still be held to meeting the same deadlines.
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