Re: time constraint policy and audio proc calls
Re: time constraint policy and audio proc calls
- Subject: Re: time constraint policy and audio proc calls
- From: Jeff Moore <email@hidden>
- Date: Mon, 19 Nov 2001 12:26:11 -0800
on 11/16/01 6:09 AM, Benjamin Golinvaux <email@hidden> wrote:
>
So, this secondary thread should also have high priority (higher than
>
Window Server) so that it doesn't block the coreaudio thread, which
>
means,
>
according to what I've read, it needs to be promoted to time constraint
>
scheduling policy.
This is the unfortunate truth in 10.1 at the moment.
>
But the time parameters of the thread ("period", "computation" and
>
"constraint") are specified using processor ticks. But this is not
>
exactly what we need : since this thread is synchronized with the
>
CoreAudio thread (it wakes up when the CoreAudio thread posts a message),
>
its period cannot be specified in processor ticks since there can be
>
a drift over time between the audio clock (audio hardware hardware clock)
>
and the processor clock.
>
>
How are we supposed to solve this problem ? Is there a way to re-trigger
>
the period at each thread wakeup ?
I don't understand your problem. Why does your feeder thread care about the
drift between the host time and the sample time?
(BTW, AudioDeviceTranslateTime help you sort this kind of thing out.)
How are you setting things up?
If I were doing this, I would set up a mechanism with input and output
queues. In my IOProc, I would pull off the next buffer for output and copy
it to the output buffer. I would copy the input buffer (if any) to an input
buffer queue for processing. I would also be sure to keep the time stamps
with the data that they go with. Then I would signal my feeder thread that
it was time to render another buffer using the data in the queues.
Since we can't make a normal thread be higher priority than the window
server in 10.1 at the moment (which is really what you want to do if you
were able), you need to be sure to configure the feeder thread's time
constraint parameters correctly so that they have as little impact on the
HAL's IOThread as possible (there will be some, which is why a normal user
thread is preferable to this were it available).
You have 4 constraints to deal with:
pre-emptible: whether or not this thread can be pre-empted
Always set this to true. Feeder threads have to be pre-emptible by the
IO treads for audio and MIDI
period: roughly how often the thread is going to wake up
For a feeder thread being woken by your IOProc, you want to set this to
the number of host ticks in one buffer's worth of data. This number does
not need to be 100% accurate to do it's job.
computation: the amount of time until the thread can be pre-empted
Feeder thread's should be pre-emptible after a very very small amount of
time, if not immediately. So, set this number very small, if not to 0.
constraint: the amount of time until the your thread becomes a miscreant
When your thread goes beyond this bound, the scheduler will treat it as
a misbehaving thread and will punish it accordingly. The scheduler will
restore the thread's status as soon as it goes to sleep. In general, you
want this number to be the same as the number you pass to the period
constraint. This warns the scheduler that you might take 100% of the
CPU. If you know that you need more or less time to do your work, you
should adjust this value accordingly.
The scheduler is not 100% accurate, so these numbers don't need to be 100%
accurate either (although accuracy doesn't hurt anything). Further, you can
adjust these numbers whenever you like (be aware that this is not a free
operation, as it involves a kernel transition).
Hope this helps.
--
Jeff Moore
Core Audio
Apple