Re: Forking and drop-outs
Re: Forking and drop-outs
- Subject: Re: Forking and drop-outs
- From: Jeff Moore <email@hidden>
- Date: Thu, 1 Nov 2007 14:57:52 -0700
So basically we're all just shooting in the dark here. I think we can
guess and suppose all day about why this is happening, but what you
really need to do is roll up your sleeves and figure out exactly what
is causing the glitching. More often than not, I find that the sort of
issues you mention have little or nothing to do with the actual cause
of the glitch. It almost always turns out to be something more
mundane, such as hitting a code path with a lock unexpectedly or
getting extra paging or just running out of time. Further, many of
these cases turn out to be issues not with what is happening on the IO
thread, but rather what is happening (or not) on the worker threads
that feed the IO thread.
BTW, I've fielded requests many times from developers who thought that
having the pager run at a priority lower than the IO thread would be a
good idea. When I worked with those developers on their actual
problems that led to them thinking that way, it has never failed to be
the case that it was the app doing something incorrect/unfortunate/
stupid that caused the actual problem. Fixing the problem always made
the request go away =)
So, here's what I'd be doing to track this down:
Use the IO cycle telemetry to narrow down what the proximate cause of
the glitch is. The telemetry makes it pretty darn easy to see if there
was any scheduling latency, whether the IO proc is delivering data on
time, etc. Once you've narrowed down the proximate cause, start poking
at it to see why using whatever tools are most appropriate (often that
will be Shark).
For example, if you find out from the telemetry that scheduling
latency is causing the IO thread to wake up late, you have a couple of
ways to figure out what is causing this. First, the IO cycle telemetry
window in HALLab can take latency kernel traces. These traces will
show the kernel events that took place during the problematic IO
cycle. From these events you can see when the IO thread was made
runnable vs. when it actually started running and what was going on in
between to keep it from running right away. Another great tool you can
use for a lot of the same data, but presented graphically, is to use
Shark's system trace profile. You can see the IO thread and the other
threads on the system and see directly what was running when the IO
thread was supposed to.
I think that the answer to your problem is only going to be found once
you narrow down what the proximate cause of the glitching is.
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:-)
--
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