Re: Overload issues
Re: Overload issues
- Subject: Re: Overload issues
- From: John Stiles <email@hidden>
- Date: Mon, 21 Jun 2004 14:24:48 -0700
Hey, we're just doing our job. End users tend to complain when we stop
loading textures and sounds. ("Hold on... why is that orc is
gouraud-shaded?")
On Jun 21, 2004, at 2:15 PM, Jeff Moore wrote:
First off: printf's from inside your IOProc pretty much guarantees
glitching, especially when the system is under memory pressure. Also,
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.
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.
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.
On Jun 21, 2004, at 1:31 PM, Glenn Maynard wrote:
I'm still having problems with overloads on some people's machines.
I've
added some rudimentary instrumentation, to measure the total time of
an
IOProc and the total time spent mixing (the only other possibly
expensive
bit is the converter).
I'm seeing inconsistent output:
WARNING: Audio overload. Last IOProc time: 0.015000 IOProc calls: 103
(0.015 0.000 0.000 0.001 0.001 0.000 0.000 0.000 0.001 0.000 0.000
0.001
0.000 0.000 0.000 0.000 ) 1
WARNING: Audio overload. Last IOProc time: 0.015000 IOProc calls: 41
(0.010 0.000 0.000 0.000 0.000 0.000 0.001 0.000 0.000 0.001 0.000
0.001
0.000 0.000 0.000 0.000 ) 1
WARNING: Audio overload. Last IOProc time: 0.002000 IOProc calls: 15
(0.002 0.002 0.002 0.001 0.000 0.000 0.000 0.000 0.003 0.002 0.002
0.000
0.000 0.000 0.000 0.002 ) 1
That's the total time, the number of IOProc calls since the last
overload,
and the time spent mixing in previous IOProc calls (the overloaded
time
coming first). All time is in realtime, so they reflect time spent if
some other thread is scheduled.
The times don't make too much sense. The first thinks the time is
spent
mixing; the second that 10ms is mixing and 5ms other, and the last
thinks
there was an overload due to a merely 2ms IOProc.
At the time of these overloads, no sounds are playing--the game is
still
loading, so the mixing call does a few trivial things and then
memset()s
the buffer to silence; I'm not sure how that could take 10ms. The
only
explanation I can think of that would explain both that and the
10ms/15ms
case is that the IOProc was losing the scheduler to some higher
priority
thread. (We have no realtime threads; the only high priority thread
is
for sound decoding, set with THREAD_PRECEDENCE_POLICY to 32, which is
idle as nothing is playing.) I can't think of any explanation for the
2ms case, unless our timer is acting up or CA is confused.
(There are also a lot of overloads happening in a row, with "calls: 0"
or other single-digit numbers. I don't know if they might just be
caused
by my overload logging; I don't know if the overload listener is time-
critical.)
The buffer size is 512 frames. The machine reports PowerMacG4, OS X
10.3.4.
I don't have access to the machine; this comes in as part of a bug
report.
We've been trying to fix this for a couple months now, and I'd like to
not have to go back to the QuickTime driver, but I'm out of ideas.
--
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.
--
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.
_______________________________________________
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.