Re: coreaudio-api digest, Vol 1 #146 - 10 msgs
Re: coreaudio-api digest, Vol 1 #146 - 10 msgs
- Subject: Re: coreaudio-api digest, Vol 1 #146 - 10 msgs
- From: Stephane Letz <email@hidden>
- Date: Thu, 29 Nov 2001 10:10:58 +0100
Message: 4
>
Date: Wed, 28 Nov 2001 11:50:15 -0800
>
Subject: Re: Threads in CoreAudio applications
>
From: Jeff Moore <email@hidden>
>
To: CoreAudio API <email@hidden>
>
>
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.
xrun means under_run or over_run, when the audio stream is not correctly
rendered.
>
>
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.
Does this behaviour of 10.1 will remain in future versions of the system?
If yes it means that the standard pthread API (using SCHED_FIFO) can not be
used for real-time audio. Is that correct?
>
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.
>
And it means that one need to use the lower level mach thread API for
real-time audio.
Stephane Letz
Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr