Re: Forking and drop-outs
Re: Forking and drop-outs
- Subject: Re: Forking and drop-outs
- From: Mark Pauley <email@hidden>
- Date: Thu, 1 Nov 2007 14:26:51 -0700
Your audio thread does operate at a higher, near-realtime priority.
Your problem may have to do with the locking of some data structures
in the kernel related to mmap'ed regions that are copied across the
fork. The ownership after the fork becomes sort of questionable. The
only process that will be affected would of course be the parent. To
work around this, you may want to try using posix_spawn which I
believe doesn't have the semantics that require a lock.
I would also recommend that you not do any interprocess communication
or use any of the posix facilities that could take a system-lock
during the audio interrupt. You're dealing with a hard-deadline and
any resource-contention shennanighans will certainly be bad for timing.
This means: you can't dynamically load any dylibs into your address
space from the audio interrupt. You should make sure that you have
all of your dlopen/dlsym (i.e. component manager) calls out of the way
_before_ you start the AU graph. I doubt you're doing this, but what
I don't understand is what you are doing during the audio interrupt
that is causing dropouts. I know that some system calls take locks
that may be needed by libDyld, perhaps you should break out Xray and
see just what your AU's are blocking on.
Perhaps it would be useful if you were to craft a small example
program that exhibits the behavior you see and post it to the list?
_Mark
On Nov 1, 2007, at 1:59 PM, Ethan Funk wrote:
I too expected that the problem was the dynamic loader, in which
case there is little I can do about it. However, it strikes me as
odd that running apps from the finder, which certainly involves the
dynamic loader does NOT cause any drop outs in my application...
consistently!
My applications IO procs all use locked memory non-blocking ring
buffers and stack variables, so external dynamic pager requests or
pager requests from other threads in my application seem the most
likely cause. I guess I'll have to crack open the CoreAudio toolbox
and see what I can find.
On a side note:
It would be nice if there was some way to tell CoreAudio (and the
underlying OS) that your audio IO Proc should run with a higher
priority than the dynamic pager if you PROMIS on your grandfathers
grave to only access locked memory in your procedure - thus
preventing deadlock.
Ethan...
On Nov 1, 2007, at 12:43 PM, Ian Kemmish wrote:
I have a modular synth AU, and I have noticed that anything that
involves the dynamic loader seems to cause drop-outs - the first
time I load a bundle for a particular modules UI, the first time I
use an OpenGL view, stuff like that. When you think about it, this
is entirely understandable...
Given that (according to my understanding) running almost anything
on Mac OS involves the dynamic loader, this *may* be part of your
problem. If so, I would expect that it's not the fork that's the
problem, but the subsequent exec. You should be able to craft a
simple test to establish this. If that is the root cause, then one
workaround might be to make sure that the code executed by the
child process is entirely statically linked.
I've just checked the man pages to refresh my memory, and it
appears that vfork() suspends the parent process while the child is
using its resources (i.e. until it exits or execs). Thus, this
appears to be one of the few cases where fork() is preferable to
vfork() and would certainly have caught me out if I was doing what
you're doing:-)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
Ian Kemmish 18 Durham Close, Biggleswade, Beds
SG18 8HZ
email@hidden Tel: +44 1767 601361 Mob: +44
7952 854387
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
_______________________________________________
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
_______________________________________________
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