Re: System preparation for realtime audio
Re: System preparation for realtime audio
- Subject: Re: System preparation for realtime audio
- From: Jeff Moore <email@hidden>
- Date: Wed, 5 Mar 2008 21:33:28 -0800
You can't run unbounded on a real time thread. Other things on the
system that run at real time, like the audio hardware and JACK itself,
won't ever get to run and no audio will come out of the system from
anybody.
That's why it sounds like the scheduler is penalizing your threads.
Basically, what seems to be happening is that your priority is
starting off in the real time band. But after it exceeds it's time
constraint, your thread's priority is degrading until it gets low
enough to get pre-empted. Eventually, you're thread is doing something
that is resetting the priority to real time (any blocking call will do
and it's possible that the scheduler is doing it for you after pre-
emption too) and the whole process starts again.
A couple of things come to mind. First, there's a good chance that you
have not described your thread's time constraints to the scheduler
correctly. These constraints aren't considered advisory. They are
promises to the scheduler to get your work done and go back to sleep
in that time frame. Running past the constraints get you the penalties
I described above. So, you really have to get these right and then
stick to them.
Second, real time threads have to go to sleep eventually. This kind of
follows on from what I said about the time constraints. The basic
model is to wake up, do the work, and go back to sleep, and do that as
quickly as possible. So, it's possible that you might achieve better
performance if you divvied the work up into pieces and put the threads
to sleep between pieces. Often, you couple doing this with increasing
the number of processing threads you have (often two per processor
works nicely).
Finally, it's entirely possible that if you re-arrange things, you
don't need to use real time threads at all. OS X is a different beast
than Linux. Applications certainly don't control interrupts, for
example, and our threading and scheduling models are decidedly
different. So, it is usually better to re-arrange your threads so that
they can run below real time where most of the important system and
hardware threads live, but still above things like UI threads. This
will yield better performance for the system as a whole. Besides, it's
never a good thing for producer threads like your processing threads
to starve out the consumer threads like the JACK threads and the
system threads JACK depends on (most notably the HAL's IO thread).
It's all a balancing act.
On Mar 5, 2008, at 4:45 PM, alejandro wrote:
We are a post-production DAW manufacturer and we are porting our
product Audiohive (www.openstudionetworks.com) from Linux to OS X.
Our app uses JACK for audio I/O and uses multiple cores for
processing. The processing threads are detached from the JACK
callback threads, in a producer/consumer model, and must have a very
good realtime response to avoid losing audio packets. In Linux there
is a way to lock threads to cores in order to avoid cache and
scheduling conflicts. Also interrupts can be redirected to
particular cores (to the ones that are not processing audio).
There is a lack of these features in OS X, but what I am
experiencing is that all these processing threads, with
THREAD_TIME_CONSTRAINT_POLICY (by far the best I have tried,
including the new THREAD_AFFINITY_POLICY), have a scheduling "stop"
every second, so the CPU meters show a peak. For 512 samples, the
peak doubles the percentage of CPU consumption, but for 256 samples
it is tree times more!!!
As you can imagine it is a huge problem for us. Thank you,
--
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