Re: Threads in CoreAudio applications
Re: Threads in CoreAudio applications
- Subject: Re: Threads in CoreAudio applications
- From: Jeff Moore <email@hidden>
- Date: Wed, 28 Nov 2001 11:50:15 -0800
on 11/28/01 3:04 AM, Stephane Letz <email@hidden> wrote:
>
- for more serious audio applications, it seems that Apple recommend NOT to
>
do the whole audio processing in the AudioIOProc because the machine
>
behaviour can be disturbed. Is there any technical reason like reantrancy
>
issues for that?
No. There is no technical reasons for not doing all your processing in your
IOProc.
>
Of course an audio application that need a lot of CPU to do it's job will
>
block the machine. But if the costly audio code is done in another thread,
>
it need the same CPU. In this case the machine will be less blocked but the
>
audio application will probaly have xruns problems. So basically the choice
>
is between a possibliy blocked machine that does its audio job correctly,
>
or a less blocked one with a audio application that does not run correctly
>
because of xruns. What is the better?
Depends on the application.
What is an xrun problem? I've never heard that term.
>
- if the application does it's job in another thread (like a pthread) then
>
one has to deal with synchronization issues between this thread and the
>
AudioIOProc.
Yes. Synchronization is always an issue with a producer/consumer model.
>
- it seems that using the standard ways like condition variables and mutex
>
using pthread API like pthread_cond_wait, pthread_cond_signal is not
>
recommended because the IOThread may be blocked by the mutex.
Yes, that is correct. Blocking the IOThread outside of the HAL's direct
control, especially for an unbounded amount of time, is going to eventually
result in your process failing to keep up in the delivery of the data.
>
So what are we supposed to use to synchronize the two threads?
Again, it depends on your application and how you handle access to your data
structures.
In my own code, I use queues that have booleans to control access. It works
because I know exactly what is going on and I've gone to great lengths to
make sure that the two threads won't interfere with each other. Will it work
for everyone? Probably not, it depends on how your code is structured.
>
Another problem if the thread priority. On Linux, and audio application
>
usually use a SCHED_FIFO thread that get realtime scheduling.
>
Can this be done also on Mac OSX?
Only processes that have root privileges can use SCHED_FIFO.
>
Or is there any other way to set the
>
priority of the application thread doing the audio code to a value that
>
garantee its correct scheduling (something like less priority compared to
>
the IOThread and more than any normal thread)
Ideally, you want an ordinary thread whose priority is lower than the
IOThread and the hardware threads (eg. USB service routines in the driver),
but higher than just about everything else, except MIDI.
In 10.1, an ordinary process can't make an ordinary thread be higher
priority than the window server (whose priority doesn't degrade either), so
your ordinary thread will get pre-empted (or not scheduled in the first
place) whenever the window server needs to do something.
Fortunately, there is the time constraint scheduling policy. This is the
same policy that the IOThread uses. This does add extra competition with the
IOThread and other important system threads (MIDI, driver service threads,
etc), you can use the constraints in a way to balance things out reasonably
well.
If you search through the archives of this list (they're archiving this
stuff somewhere, right?), you can find a few recent posts that talk about
using time constraint policy threads and how to configure them.
--
Jeff Moore
Core Audio
Apple