Re: IOProc limitations
Re: IOProc limitations
- Subject: Re: IOProc limitations
- From: Jeff Moore <email@hidden>
- Date: Wed, 30 May 2001 19:24:03 -0700
on 5/30/01 3:54 PM, James McCartney <email@hidden> wrote:
>
Does OSX/CoreAudio do priority inversion to bump my thread up if I'm holding
>
a mutex to change some data structure like for instance an in-memory sound
>
file header?
The HAL doesn't touch other thread's priorities. It's IOThreads are Mach
real-time threads. As such, they are the highest priority threads in the
system, capable of pre-empting just about everything.
As a general rule, it is a really bad idea to stall the IOThread by waiting
on a mutex or something like that. You'll really hose your timing if the
IOThread has to sleep outside of the HAL's direct control.
Your IOProc should do it's business as quickly as possible and return. The
best possible thing would be if the IOProc simply blitted data that had
already been prepared ahead of time by another thread, as you seem to be
trying to do.
>
I tried to fill my audio outside of the callback by synchronizing with a
>
condition. It worked, but dragging windows would cause dropouts. Filling the
>
buffer inside the callback does not cause dropouts.
>
>
Can this scheme be done correctly by setting up priorities or something
>
else?
>
>
The idea is that I would like to have a { getcommand; processcommand } loop
>
that runs indefinitely processing commands where filling an audio buffer is
>
just like any other command. This lets the same thread operate whether the
>
audio is turned on or not. Thus it could switch from processing audio in
>
real time to some other task.
>
>
If that kind of scheme is not possible then I have to exit one thread and
>
start processing commands in the audio loop and if audio is turned on then
>
go back to a thread again.
I think your trouble is that the audio producer thread is lower priority
than the window server's thread (and likely most of the other threads in
your process). This is causing it to not produce the data in time to be
copied in the IOThread (if I understand your scheme correctly).
Try doing a 'ps -auxM' while your app is running. It will list all the
threads in each process and their priorities. You should then pick a
priority that is appropriate for your app's situation. Likely, it will be in
the 40's or possibly higher.
You're on the right track it seems. Boosting your producer thread's priority
ought to do the trick for you.
--
Jeff Moore
Core Audio
Apple