Re: Overload issues
Re: Overload issues
- Subject: Re: Overload issues
- From: Jeff Moore <email@hidden>
- Date: Mon, 21 Jun 2004 14:15:34 -0700
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.