Overload issues
Overload issues
- Subject: Overload issues
- From: Glenn Maynard <email@hidden>
- Date: Mon, 21 Jun 2004 16:31:38 -0400
- Mail-copies-to: nobody
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.