Re: Audio processing thread realtime priorties
Re: Audio processing thread realtime priorties
- Subject: Re: Audio processing thread realtime priorties
- From: Wolfgang Kundrus <email@hidden>
- Date: Wed, 10 Jun 2009 21:43:30 +0200
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