Re: Audio threads scheduling (Modifié par St éphane LETZ)
Re: Audio threads scheduling (Modifié par St éphane LETZ)
- Subject: Re: Audio threads scheduling (Modifié par St éphane LETZ)
- From: Stéphane LETZ <email@hidden>
- Date: Sat, 3 Apr 2004 13:23:46 +0200
- Resent-date: Sat, 3 Apr 2004 21:23:16 +0200
- Resent-from: Stéphane LETZ <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: email@hidden
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?
Well, I tried to answer William Stewart request to give examples of
reproductible scenarios that cause problems with the MillionMonkeys
application that anybody can test.
And as explained using fixed 63 priority threads to test thread
interleaving with different buffer size does not work well. I guess
that in this case, the thread with the larger buffer size runs for too
long and is not preempted by the thread using the small buffer size.
But basically, you and William are saying ; the 63 thread scheduling
should work, i tried this, give some reproductible scenarios that cause
problems and expect to get some explanations of the seen behaviour.
Either the tests are not correct or using 63 threads is not the way to
do.
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):
Hum, i think understanding the internals help having a clear picture of
what is going on!
- 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.
Thanks a lot.
- 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.
If I understand correctly, a "normal" IO thread is waken regularly at
each audio cycle beginning, does it's job (possibly in several steps
since it may be preempted by other real-time threads) then is
suspended again.
And suspension is done using a "pthread_cond_timewait" (or something
similar) which period equal the buffer size duration. Is this correct?
Now if a thread is suspended *inside* it's audio cycle because it is
waiting on another ressource (a lock or mutex ) but will be unlocked in
the *same* audio cycle, the scheduler will elect another thread and
will have to go back to the suspended real-time thread during the
*same* audio cycle to finish it"s job.
So if first case, the scheduler knows that the thread will be suspended
until the next audio cycle, because of the use of the
pthread_cond_timewait call, and in the second case the scheduler does
not know when the thread is going to be runnable again.
This, in effect, extends the non-pre-emptible
section of the cycle a great deal and again leads to the priority
inversion.
Why? if the thread is suspended on a mutex for example, control go back
to the scheduler that is free to schedule another real-time thread?
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.
--
Basically I'm designing an application that will evaluate a graph of
connected audio components and I would like to take profit of
bi-processors machines. Although i read some older mails that advice
against that... I ' am trying to understand under what conditions it
could be done in a correct way. The idea is to have lock-free list of
runnable sub tasks and a "mini-scheduler" that will feed one thread
running on each processor. At some point in the audio cycle, one thread
may have to wait the other one to finish because of data dependencies.
Thus inside an audio cycle, each thread may have to be suspended but
resumed in the same cycle.
Stephane Letz
_______________________________________________
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.