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: Fri, 12 Jun 2009 00:44:25 +0200
Hi Bill,
I have solved my problems now with the information I got. For one,
putting the mixing into a separate thread got rid of the overloads.
Then I had a problem with the priority setting that woud leave no time
for the audiodevice, in this case it was a specific device on the
firewire bus that caused the problem. I have bounded the computation
part of the time constraint policy to a mximum of 3 ms and that solved
the dropouts at 2048 samples buffersize.
Thanks for the help
Wolfgang
2009/6/11 William Stewart <email@hidden>:
> 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
>
>
--
Managing Director
PreSonus Software Limited
Bei der Neuen Muenze 1
22145 Hamburg, Germany
Phone: +49 (0) 40 - 2851 0694
Mobile: +49 (0) 171 - 273 04 70
Fax: +49 (0) 40 - 2851 0696
Web: www.presonus.com
_______________________________________________
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