Re: Overload issues
Re: Overload issues
- Subject: Re: Overload issues
- From: Glenn Maynard <email@hidden>
- Date: Mon, 21 Jun 2004 18:03:18 -0400
- Mail-copies-to: nobody
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.)
>
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.
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).
The only time I see any allocations happening in the IOProc is in our
mixing buffer, and that only happens once. Everything else is just
simple lockless buffer access--and there isn't even any of that here,
since nothing is playing.
>
That said, I've had the pleasure of profiling several big time games.
>
By far, the most common cause of audio glitching is VM paging activity.
>
Games seem to just blindly load textures, sounds, etc. into memory
>
without any regard to the of memory pressure that subjects the machine
>
to. Your comment where you say "At the time of these overloads, no
>
sounds are playing--the game is still loading" sure sounds like it
>
would fall into this case.
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.
>
From what I've seen, this problem seems endemic to the way video games
>
are designed and developed. When I've reported these findings back to
>
various developers, the response I've gotten has been pretty much to
>
get more memory in my system. While it solves the problem, it doesn't
>
really address the reason it came about in the first place. A real
>
solution would involve figuring out a streaming mechanism to move
>
assets off the disk and into memory as they are needed rather than just
>
slamming the system with all of them at once and letting the VM system
>
deal with it. This amounts pretty much to taking ownership of your
>
asset management and tailoring a solution for your specific situation
>
rather than relying on the sometimes capricious-seeming and more
>
general purpose VM system to do it for you.
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.
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.
--
Glenn Maynard
_______________________________________________
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.