Re: Overload issues
Re: Overload issues
- Subject: Re: Overload issues
- From: Doug Wyatt <email@hidden>
- Date: Mon, 21 Jun 2004 14:30:33 -0700
I'm assuming you can reproduce this somewhere ...
Hopefully I'm not sending you off into the deep end ... but you could
try setting up Shark as follows:
- Click Config
- Under Trigger, change "Timer" to "OS PMI". "PMC1" should be selected.
Enter "1" to the left of the "PMC1" pop-up.
- In the right-hand set of tabs, click MacOS. For PMC1, choose "3 - VM
Page Ins" or "1 - VM Faults".
The status box at bottom left should now read:
- Sampling begins immediately.
- A sample is taken every 1 OS 'VM Page Ins' Events.
- Sampling ends automatically after 30000 samples have been taken or
when stopped manually.
Run your app with Shark sampling enabled.
Note that Shark can cause further dropouts. That's OK; it may point you
to one before it causes any of its own. End sampling. Now you should be
able to see if any VM page ins or faults happened on your I/O thread.
If so, where and why?
Doug
On Jun 21, 2004, at 13:31, 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.