Re: Overload issues
Re: Overload issues
- Subject: Re: Overload issues
- From: Jeremy Sagan <email@hidden>
- Date: Mon, 21 Jun 2004 20:18:03 -0400
Doug,
Thank you for this. Excellent instruction. Shark is also amazing. I had
a question about this however. I get a message from Shark that says:
"This instruction appears to be the start of a loop that is not aligned
to a 16-byte address boundary. For optimal performance, you should
align the start of a hot loop using a compiler directive. In
CodeWarrior 8, use #pragma function_align 16. In CodeWarrior 9, it is
also possible to use 'asm {align 16}' (broken in CodeWarrior 8). With
gcc, use the -falign-loops=16 compiler flag (broken in gcc 3.1; gcc 3.3
or later should be used)."
Codewarrior 8 will not align this loop with pragma function_align 16.
Does anyone know how to align a loop in Codewarrior 8?
Thanks,
Jeremy
On Jun 21, 2004, at 5:30 PM, Doug Wyatt wrote:
>
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.
_______________________________________________
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.