Re: small buffer size
Re: small buffer size
- Subject: Re: small buffer size
- From: Shaun Wexler <email@hidden>
- Date: Mon, 17 May 2004 06:23:08 -0700
On May 17, 2004, at 4:12 AM, David Duncan wrote:
Personally, if your visual doesn't work well drawing more than 32
sample at a time, I would look at revising your visual. Even at 512
samples drawn that is an 86Hz refresh rate, which is faster than many
monitors can keep up.
FWIW, MacFOH draws with perfect display-refresh sync and maintains max
frame rate, independent of audio/DSP sample rates. Things are quite
smooth and fluid at max fps; the key of course is to choose the
appropriate averaging coefficient (exponential scale factor, etc) so
the graphics respond with the proper physics to balance the eye's
ability to focus as well as the display's ability to "keep up" with the
pixel refreshes. LCD's are notorious for being slow, and even at 60
fps the graphics are hard to follow each frame unless you use a bit
longer averaging periods than on a CRT.
A very strong point to make here is that NOBODY should even consider
performing non-DSP tasks in a real-time thread or AU rendering
callback. All that does is slow down the rest of the system, when the
graphics could easily be handled in a timesharing thread. I have no
problems with this, and in fact don't even need to use multiple
(graphics & post-DSP) rendering threads to maintain max performance.
This is an interesting subject, since I will be adding (Cocoa) AU
hosting to MacFOH, as well as creating an AU shell component to enable
its analyzers and features in other AU host apps. Are there any actual
Cocoa-only AU hosts out there? Damn, I don't want to be the first...
;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
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.