Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Jeff Moore <email@hidden>
- Date: Fri, 2 Apr 2004 14:26:18 -0800
On Apr 2, 2004, at 12:50 PM, Stiphane LETZ wrote:
Basically I'm testing the MillionMonkeys application.
- using the "occurs production in the feeder thread" in "fixed
prority" mode with a small buffer size, like 64 frames, 40% CPU load,
one get occasionnal drop out when launching applications for example.
- to test real-time thread interleaving, I use 2 copies of the
MillionMonkeys application:
- with same buffer size settings (64). Using the "occurs production
in the feeder thread" in "fixed prority" mode , 40% CPU load for both
applications. One get occasionnal drop out when launching application
for example.
- with different buffer size settings (64 and 512 for example). Using
the "occurs production in the feeder thread" in "fixed prority" mode ,
40% CPU load for both applications. One get constant drop out when the
application that use the larger buffer size (512) in on front and
occasionnal drop out when the application that use the smaller buffer
size (64) is in front.
- with "occurs production in the feeder thread" in "real time" mode,
with different buffer size settings (64 and 512 for example) they are
drop out with the way the real time thread computation parameter is
computed in the given code (that 15% of the buffer time slice defined
setThreadToPriority ). If the computation parameter is computed the
way it is done in the IO thread (that is larger values for small
buffer sizes), things are going well (no more drop out) as explained
in the previous mail.
My conclusion from this is that using a real time thread is way more
dangerous and disruptive to the rest of the system.
The problem is that they are essentially the highest priority running
on the system. So, you then start to compete with yourself for doing
I/O tasks (like the I/O thread of CoreMIDI as well as Audio Device
I/O).
Sorry but I don't understand this way of reasonning!
You're not competing with yourself , you're trying to get several
real-time threads with different needs (period, CPU need..) be
scheduled in a proper way.
In other words, these threads are competing with themselves since all
real time threads, regardless of their parameters will be scheduled
round-robin fashion if they are runnable.
They are a set of real-time threads with different period and CPU
need, and the issue is to give the scheduler informations to help it
interleaving thread computation to meet the thread deadline. The way
it is done on Darwin , with a unique 97 priority *and* a way to
describe the period, computation, and constraint parameter seems more
adequate compared to Linux for example where one need to play with
thread priority to solve interleaving issues: real-time threads with a
smaller period need a higher priority to correctly preempt real-time
threads with a larger period.
Making more real time threads just means that there is more
competition. Which makes it that much harder for the scheduler to
satisfy anybody's needs.
But in any case we have 100 % CPU time and the issue is to devide this
time correctly. Of course some applications like Direct to disk
systems can use additionnal lower-prority (for example fixed 63). But
when they are required to produce audio at a certain rate, like in the
MillionMonkeys application it seems that using a fixed 63 thread is
not adequate.
I have seen plenty of systems that provide a counter example.
The real question that you have to ask is why isn't the pri 63 thread
getting the time it needs?
I think that the questions about threads scheduling come again and
again because it is a very hard to get *precise* informations about
the way things are done in the HAL. For example:
- how are computed the "computation" parameter for proper audio
thread interleaving?
- how is computed the "computation" parameters for Midi threads, how
does this interact with audio threads.?
- why is it "forbidden" to suspend a real-time thread?
Having this kind of information would be very helpful.
I would argue that you don't need to know the answers to your questions
to make a system that performs well. Here are the answers though, since
none of this is any big secret (no one has ever asked before):
- how are computed the "computation" parameter for proper audio
thread interleaving?
For IO audio based devices (note that devices that are implemented
through other means don't necessarily follow this procedure), the HAL
has three classifications for the duration of an IO cycle: short,
medium, and long (I forget what the ranges are, but I think they are
1.5ms and below, 4.5ms and below, and everything else). For each
classification we have fixed value for the computation parameter.
- how is computed the "computation" parameters for Midi threads, how
does this interact with audio threads.?
I think Doug did a bunch of experiments to figure out a "good" value
for it that meets the MIDI server's needs while not overly interfering
with other real time threads.
- why is it "forbidden" to suspend a real-time thread?
It isn't. The advice is to not suspend the IO threads of either the HAL
or the MIDI server as that disrupts their timing. The other issue is
that the scheduler has no way of telling the normal suspension of the
thread because the cycle is complete from a client suspending it to
lock a mutex or whatever. This, in effect, extends the non-pre-emptible
section of the cycle a great deal and again leads to the priority
inversion.
So far, everything you've written is pretty theoretical. If you have a
real example of a real problem in something you are working on, please
describe that. We can do some instrumentation, look at kernel traces,
etc. and figure out what's going on. This theoretical stuff is great,
and I can talk about it all day, but it won't get you anywhere with
your problems. More times than I can count, the true problem with
glitching turns out to be something much more mundane than a scheduling
problem.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.