Re: Overload issues
Re: Overload issues
- Subject: Re: Overload issues
- From: Jeff Moore <email@hidden>
- Date: Mon, 21 Jun 2004 18:53:33 -0700
On Jun 21, 2004, at 3:03 PM, Glenn Maynard wrote:
On Mon, Jun 21, 2004 at 02:15:34PM -0700, Jeff Moore wrote:
First off: printf's from inside your IOProc pretty much guarantees
glitching, especially when the system is under memory pressure. Also,
I'm only printing from within the overload listener, and only when
there's
an overload. (I'm now also only logging when there were at least 100
non-overload IOProc calls since the last one, to cut down the output.)
Your overload listener is generally called from the IO thread. I was
only mentioning this because you were confused about why you were
seeing several overloads in a row and this is usually the reason why.
when you are measuring times in the IOProc, my guess is that you are
doing it in a way that allows the IO thread to get pre-empted (calling
printf or malloc is a good way to do this). This is why the times seem
to be a little wild. You'd probably get more usable results using a
tool like Shark or Saturn to do your profiling.
The timer uses gettimeofday(); all times are stored in small, global,
static
buffers. If there's a better call to use for this type of timing, let
me know.
The most accurate clock on the system is the one defined by
mach_absolute_time(). Easy access to it can be had with
<CoreAudio/HostTime.h>
This problem only happens on user machines; none of us have access to a
machine to reproduce it (or it would be an order of magnitude easier
to fix).
I know the feeling.
The log reported a full gig of memory, and our game can usually fit in
30
megs or so (probably a bit more on OSX). I can run on ALSA with a
256-frame
buffer in Linux 2.4 (compared to the default 1024-frame buffer--double
buffered 512--in CA) on a 256-meg machine.
VM paging still happens, even on when there is lots of free physical
RAM lying about. A common case is when code is run for the first time
(which doesn't seem to be the case here). It can also happen the first
time you access memory after it has been allocated.
We load the data needed for a given screen before displaying it; movies
and BGM sounds are streamed. Excessive streaming in portable games is
generally a bad idea; it puts too much pressure on the scheduler and
IDE
(most of our users are in Windows) layer, and results in skipping.
I do load some sound effects on demand, in a thread. They come from a
large pool of effects, too large to decode in advance; I do the load
in a thread, since the random seek usually takes a long time (~10ms,
a disk seek), which is enough to cause a skip. However, even in a
thread, it still often causes a frame skip in Windows. Loading other
resources this way instead of preloading them would cause more
skipping,
and due to the nature of our game, frame skips are a showstopper.
Also,
as often as not, we're simultaneously displaying almost every graphic
we
load, anyway.
It's all I balancing act. Getting it right on various platforms can be
tricky
I don't see how this could be the problem, though; the issue is being
reported on a system with four times as much memory as my Linux
machines,
workstation, which almost never underruns with 1/4 the buffer size.
I probably shouldn't jump to conclusions without more info. Shark can
certainly tell you for sure whether VM is an issue here or not. As Doug
said, it can be educational to run it even on a machine that doesn't
exhibit the problem.
If we set VM issues aside, the question to ask is why isn't the HAL's
IO thread getting the time it needs? To figure that out, you need to
figure out whether the overload is being caused by the IO thread just
waking up late or if it's something taking an unusually large amount of
time in the IOProc.
There aren't too many things that can cause the IO thread to wake up
late since it is a time constraint thread. VM is of course one of them,
and the others usually have to do with hardware interrupts (too many or
turned off too long). There are probably a few other things I'm
forgetting. The latency tool is a good tool for looking for scheduling
latencies. You can even embed the code in your app to take traces from
your overload listener.
There is another tool you can use to peek in on the workings of the HAL
called HALLab. You can find the code in
/Developer/Examples/CoreAudio/HAL/HALLab. Once you build it, you can
use the IO cycle telemetry window (accessed via the File menu) to
attach to the HAL running in another process. The window will display
the vital statistics of each IO cycle for the chosen device. It logs
the cycles with overloads in red and should provide enough context to
say which part of the cycle is causing the overload. The data displayed
in the window includes all the time stamps passed to IOProcs and info
about how late the IO thread woke up versus when it was suppposed to
wake up. There isn't any docs on this, so feel free to ask more
questions.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.