• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Overloads
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overloads


  • Subject: Re: Overloads
  • From: William Stewart <email@hidden>
  • Date: Mon, 24 May 2004 11:23:31 -0700

You might want to profile the code with the Shark tool
(Developer/Applications/Performance) - you can set that to detect vm
page ins, cache misses, etc... You might see something using this that
isn't actually causing an overload on a faster machine, but is
potentially problematic

Bill

On 21/05/2004, at 9:37 PM, Glenn Maynard wrote:

> We're having reports of overloads on older machines, especially during
> data loading.
>
> This is hard for us to track--there's only one of us on a Mac, he's on
> a new machine that doesn't have the problem, and we don't have access
> (even remote) to any that do.
>
> The code is fairly standard, as far as the IOProc is concerned: grab
> data from some lockless FIFOs, mix them together, passing the results
> through an AudioConverter. The mixing isn't heavily optimized, but
> during loads, only a BGM is playing, so that isn't being stressed.
> All decoding happens in a separate thread, which is priority boosted
> (or the IOProc was starving during loads) but not realtime.
>
> For reference, if anyone's bored enough to actually read code:
>
>
> http://cvs.sf.net/viewcvs.py/stepmania/stepmania/src/arch/Sound/
> RageSoundDriver_CA.cpp?view=markup
>
> and an example log:
>
> http://www.stolaf.edu/people/voss/files/info.txt
>
> I'm hoping somebody can point out something obviously wrong that I'm
> overlooking. If I had access to a machine that can reproduce the
> problem,
> I could track it down further, but currently all I can do is add logs,
> wait until the next testing snapshot is released (1-2 weeks), and wait
> for
> bug reports to arrive to see the results--a slow turnaround.
>
> (I ran some basic stats before releasing a snapshot recently, tracking
> average time--under 1ms per IOProc buffer--but I should have tracked
> worst-case times, or perhaps keep track of the duration of the last
> IOProc, and log it in the overload handler, which I'll do for the
> next snapshot.)
>
> --
> 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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056

________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.


References: 
 >Overloads (From: Glenn Maynard <email@hidden>)

  • Prev by Date: Re: AU Host Sample?
  • Next by Date: Re: AUValidation skips AUPeakLimiter Limiting Amount shown in AudioUnitHosting+Logic
  • Previous by thread: Overloads
  • Next by thread: Undefined symbols (oh no not again)
  • Index(es):
    • Date
    • Thread