• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Audio processing thread realtime priorties
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: Audio processing thread realtime priorties
      • From: Wolfgang Kundrus <email@hidden>
References: 
 >Re: Audio processing thread realtime priorties (From: Wolfgang Kundrus <email@hidden>)

  • Prev by Date: Re: Audio processing thread realtime priorties
  • Next by Date: Re: DLSMusicDevice and SoundFont compatibility
  • Previous by thread: Re: Audio processing thread realtime priorties
  • Next by thread: Re: Audio processing thread realtime priorties
  • Index(es):
    • Date
    • Thread